Een iets uitgebreidere samenvatting van 'self testing code' is dat je deze 'knop' realiseert door in een code naast de applicatiecode ook test code op te nemen. Deze test code roept de applicatiecode aan, en controleert dat deze de verwachte output krijgt. Hierbij is ook het doel dat er een hoge 'code coverage' haalt, typisch een line coverage van 80% in onze opleiding. Maar de afspraak hierover verschilt per bedrijf, en is ook afhankelijk van de complexiteit van de codebase (die - bij DDD aanpak - als het goed is vooral afhangt van de complexiteit van het onderliggende domein...). De vereiste code coverage hangt ook af of de codebase een monoliet is, of een microservices architectuur (MSA) heeft. Bij die laatste krijgen integratie testen meer belang en unit tests wat minder, en is code coverage minder van belang (want bij integratie tests is het geautomatiseerd bepalen van code coverage onmogelijk, of in ieder geval ingewikkelder/nog niet standaard).

Hoe dan ook, de interne werking is dus:

Figuur 2: Intern onderscheid tussen test code (grote O 1) en (vangt de 'inherente' complexiteit conform DDD)

Net als TDD gaat BDD een stap verder dan enkel 'self testing code', want BDD is ook 'test driven'. Door eerst de test code te schrijven, denk je meteen vanuit 'client' kant aan welke interface je methode moet hebben, hoe je deze aanroept, en wat deze teruggeeft. Deze 'HOE roep ik het aan?' zit meer aan de WAT kant: "WAT is de interface", omdat de echte 'hoe' kant is: 'Hoe implementeer ik de code zodat deze daadwerkelijk het verwachte resultaat' teruggeeft. TDD grondlegger Kent Beck (van het Agile Manifesto) noemt dit in zijn article 'Canon-TDD' (2022) de 'Interface/Implementation Split':

"The first misunderstanding is that folks seem to lump all design together. There are two flavors:

1. How a particular piece of behavior is invoked.
2. How the system implements that behavior."

BDD -> Geen unit maar integratie tests!

Laten we in de nieuwe 'AI age' waar we in lijken te zitten, sinds de (hype rondom) de introductie van ChatGPT

Me: Wat voor soort testen doe je bij behaviour driven development (BDD)? Kun je deze kort samenvatten in Jip en Janneke taal!?

ChatGPT: Bij Behavior-Driven Development (BDD) worden verschillende soorten testen gebruikt om softwaregedrag te specificeren en te valideren:

• Acceptatietesten: Test of de software doet wat de baas wil.
• Scenario's: Verhalen schrijven over hoe de software moet werken.
• Unit-tests: Kleine stukjes code testen om te zien of ze goed werken.
• Integratietests: Controleren of alle stukjes samenwerken zonder problemen.
• Automatisering: Tests laten de computer uitvoeren om tijd te besparen.
• Regression Testing: Kijken of nieuwe veranderingen geen oude fouten veroorzaken.

Figuur 3: De test pyramide (Bron: headspin.io - Open commons licentie)

ChatGPT geeft een mooi overzicht van verschillende soorten tests, die je als developer moet kennen. Maar om unit tests op te nemen in dit overzicht van voor BDD relevante testen is wel een fout van ChatGPT (terzijde: AI modellen/systemen laten zich helaas NIET goed unit testen vanwege hun non-deterministische gedrag). Dus daarom is dit doorgestreept. Want BDD richt zich dus op juist op integratietests of zelfs end-to-end tests (integratie tests over alle lagen/units/functionaliteit heen). Lees bv. op de Cucumber Blog website (z.d.), dat je Cucumber gebruikt voor integratie en end-to-end tests, en NIET voor unit tests:

"BDD should also be used to verify the wanted behaviour using integration tests.

[...] These unit tests will not be validated by a stakeholder as they are written in code, and most stakeholders don't read code. If they did we wouldn't need tools like Cucumber."

De regressie tests die ChatGPT vermeld zijn GEEN wezenlijk verschillende tests van de andere tests die hij eerder noemt. Want je gebruikt je unit-tests en integratie-tests ook als 'regressie tests' om eventuele regressie fouten op te sporen en/of uit te sluiten. Regressiefouten zijn fouten uit stukjes code die 'omvallen' als je later wijzigingen aanbrengt in andere delen van de code waarvan je denkt dat die ongerelateerd zijn, maar die toch aan elkaar gekoppeld blijken (te weinig 'loos coupling').

Je moet de kracht en bedoeling van de verschillende tests kennen:

• Het voordeel van een unit test boven een acceptatietest is dat deze duidelijker aanwijst waar de fout vandaan komt (namelijk 1 specifieke unit).
• Het nadeel van units apart is dat deze soms geen fouten aantonen gaan, maar dat er alsnog integratie errors tussen de units buiten beeld blijft, die een acceptatie test wel aanwijst.
• Het voordeel van een integratie test is dat deze die fout wel laat zien
• Net nadeel van een integratie test is dat deze een fout niet aanweijzen
• En een nadeel is dat deze langzamer zijn, om dat bv. echt de database gebruikt word. Bij een unit test moet je externe dependencies/systemen als database altijd mocken

The Three Amigo's

Figuur 1: The three amigo's en het BDD proces met 3 stappen+1(van Pluralsight)

"The 'Three Amigos' is a meeting that takes user stories and turns them into clean, thorough Gherkin scenarios. It involves three voices (at least):

• The product owner
• The tester
• The developer

https://johnfergusonsmart.com/wp-content/uploads/2017/11/iStock-147318638-1024x683.jpg

Figuur 2: The three amigo's, niet per se 3, niet per se Spaans, maar wel per se >=3, divers en onderling vriendschappelijke omgang :)

BDD: 'Executable specifications' en synonieme acro's voor BDD

Gherkin is the most commonly used plain-text language for writing executable specifications in Given-When-Then-And-But steps. These scenarios are commonly saved as .feature files.

Feature: Users should be able to book appointments.

Scenario: A user wants to book an appointment.

Given a user has booked an appointment

When the booking status is timed out

Then the appointment will be not confirmed

Bron: 'What are executable specifications?' - Cucumber.io blog, 7-2-2019

... "BDD aims to express requirements unambiguously, not simply create tests. The result may be viewed as an expression of requirements or a test, but the result is the same. Acceptance tests record the decisions made in the conversation between the team and the Product Owner so that the team understands the intended behavior.

There are three alternative labels to this detailing process:

• Behavior Driven Design (BDD)
• Acceptance Test–Driven Development (ATDD)
• Specification by Example (SBE)

Bron & ©: Scaled Agile, Inc.

Lesvragen

Behandelen opgekomen studentenvragen n.a.v. huiswerk of behandelde theorie. Als er geen vragen zijn, dan staan we even stil bij deze vragen:

1. Kun je in algemeen zowel TDD als BDD doen in een project, of moet je kiezen?
2. Welke CDMM checkpunten zijn relevant voor BDD?
3. Voor Java is er Cucumber, voor .NET is erSpecFlow of ReqNRoll, maar welke taal gebruik je wel in beide voor BDD?
4. Wat is een test suit? Heeft een applicatie een testsuite?
5. Het Gherkin voorbeeld op de pagina toont één feature met één scenario. Is dit typisch, of horen bij één feature vaak meer scenario's, of bij één scenario meerdere features?

Quiz

Check je kennis over BDD met onderstaande korte multiple choice toets.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kent de relatie van BDD met TDD, DDD en Agile/DevOps
  • met o.a. relevante begrippen als Ubiquitous Language, test-first, red-green-refactor, AAA pattern, given-when-then en collaborative development
• Je kent de BDD three amigo's, en de 3 stappen van het iteratieve BDD proces
• Je kent 2 andere namen van BDD, en kunt deze uitleggen
• Je kent de term 'self testing code' en het onderscheid tussen .feature files, glue code en applicatie code en de talen/standaarden die hier achterin zitten
• Je kunt de verhouding uitleggen tussen BDD test scenario's, test cases en suites met user stories en acceptatiecriteria uit Scrum
• Je kent de test pyramide, het belang van de verschillende soorten testen hierin en de link met BDD
• Je kunt op basis van een tutorial een project met werkende en relevante BDD tests opstellen m.b.v. Cucumber of Specflow (ReqNRoll)

Bronnen

• Beck, K. (1-12-2023) Canon TDD - Software Design: Tidy First? Substack.com. Geraadpleegd september 2024 op https://tidyfirst.substack.com/p/canon-tdd
• Fowler, M. (1 mei 2014) Self Testing Code martinfowler.com Geraadpleegd september 2024 op https://martinfowler.com/bliki/SelfTestingCode.html

Dev workshop 3 - Micro Frontends

Voorbereiding

• Lees uit het artikel Micro-Frontends op martinfowler.com (Jackson, 2019) de hoofdstukken:

  • Benefits
  • The Example
  • Integration Approaches

• Verzin 2 toetsvragen over het onderwerp van Micro-Frontends

  • Zet je 2 vragen in de thread hierover op het MS Teams Team van je klas/de minor
  • (Als deze er nog niet is, vraag je docent dan, of start deze thread zelf)
  • Formuleer bij voorkeur een multiple choice vraag met 4 antwoord opties waarvan 1 goed is (en 2 anderen plausibel zin)
  • Verzin een unieke vraag (e.g. hoe sneller je er een post, hoe makkelijker)
  • De beste vragen kunnen daadwerkelijk in de toets komen

Figuur 1: De microfront-end architectuur volgt vaak component structuur op het scherm/ontwerp (Jackson, 2019)

Lesprogramma

• Bespreken toetsvragen
• Mentimeter
• In teams uit elkaar
• Build your own MF met create-mf-app
• Plenair samenkomen: benefits & integration approaches

Figuur: Microservices everywhere (bron: Aditya,m 2022))

In teams uit elkaar

• 5 teams. Elk team krijgt één 'integration approach' om te gebruiken en een 'benefit' toegewezen om kort uit te leggen.

  1. Onderzoek hoe deze integration approach in zijn werk gaat.
  2. Onderzoek voor- en nadelen.
  3. Maak of vindt een kleine demo van approach
  4. Vat de toegewezen 'mf benefit' samen
  5. Presenteer je resultaten aan de rest van de klas
  6. Einddiscussie: Zou je MF's gebruiken in project, of niet. Wat is het alternatief? Als MF moet; welke integration approach zou jij het eerst kiezen voor front-end in het project?

Integratie methoden:

• Server-side template composition
• Build-time integration
• iframes
• JavaScript
• Web Components

Voordelen:

• Incremental upgrades
• Simple, decoupled codebases
• Independent deployment
• Autonomous teams
• De 5e: Bonus, niet echt voordeel, maar leg de 'Two Pizza rule of Amazon uit' + hoe dit pizza plaatje aansluit bij onderwerp microfront-ends?

Create-mf-app

Ga nu in tweetallen aan de hand van het artikel van logrocket (Patel, 2024) zelf aan de slag met het maken van een MF-app.

• Maak een simpele applicatie waarin 2 micro-frontends met elkaar moeten communiceren of in ieder geval van de resultaten van een actie gebruik moeten maken. Bijvoorbeeld:
  • Zoekbalk, Artikellijst
  • Boodschappenmand, Productenoverzicht
• Spreek met je teamgenoot af hoe je tussen de 2 micro-frontends gaat communiceren. Denk na over opties als:
  • pub-sub
  • externe service
  • browser internals
  • store/state-manager die beiden applicaties toegang tot hebben (e.g. redux, mobx, vuex, rxjs)

Quiz

Test je kennis over micro front-ends met deze multiple choice quiz:

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kunt gegeven een opdracht aangeven of een microfrontend een goede keuze is.
• Je kent het concept module federation, en kent twee andere manieren om micro-frontends met elkaar te integreren
• Je weet wat een micro-frontend is wat enkele voordelen ('benefits') hiervan zijn en kent de relatie met microservices.

Continuous Delivery vs DevOps

Huiswerk

1. Bekijk het interview met Gene Kim over 'zijn' 3 ways of DevOps
2. Bekijk het animatiefilmpje van Rackspace over 'What is DevOps'
3. Beantwoord voor jezelf onderstaande vragen over deze bronnen (zet deze in een markdown bestand `<les-cd-antwoorden-mijn-naam.md> in je weekopdracht)
4. Lees deze week de reader DevOps H10: 'Code Management' ((Sommerville, 2018) students only acces in GitHub; NB: vragen in theorietoets!)

1 Vragen bij Reader DevOps

• Wat zijn de 3 hoofdpunten belangrijkste principes* van DevOps uit Sommerville's hoofdstuk over `DevOps and Code Management'? (p. 307)
• Hoe verhouden deze 3 punten zich tot de punten uit de twee filmpjes over DevOps van Gene Kim en RackSpace? Schrijf wat je opvalt, wat verschilt en overeenkomt.

2. Vragen bij interview Gene Kim

Beantwoord de volgende vragen:

1. Wat bedoelt Kim precies met zijn 'peeing puppy' analogie? Schrijf een korte paragraaf hierover.
2. Hoe moeten jullie straks tijdens het tweeweekse project dat de DevOps course afsluit om gaan met deze 'peeing puppy'? (E.g. wanneer moet deze 'zindelijk' zijn?)
3. Kun je beter beschrijvende namen vinden verzinnen voor de three ways dan Kim's cryptische 'First way', 'Second way' en 'Third way'? Geef deze! #namingThings

3. Vragen bij animatie filmpje DevOps

Beantwoord onderstaande vragen bij het filmpje. Dit is een check of je gekeken hebt, maar ook voor activering van je voorkennis en duidelijk krijgen verschil in voorkennis en mening tussen jou en collega studenten.

NB: Het is niet erg als je voorkennis niet hebt, beantwoord wel sowieso de vragen die het filmpje zelf geeft en de mening vragen. Je hoeft niet te gaan googlen o.i.d voor de overige, tenzij een vraag dit expliciet vermeldt.

1. Welke 2 typische deploy omgevingen ('environments') worden genoemd in het filmpje? Welke hoort bij Anna en welke bij Dave?
2. Ken jij nog meer omgevingen dan deze twee? Hoe noem je deze als ICT'er? Welke hiervan zal of moet elke ICT organisatie in ieder geval hebben?
3. Vergelijk deze extra 'tussenliggende' omgevingen met de 2 van vraag 1. Stel dat de software een typische 3-tier webapplicatie is, e.g. website met wat business logica en een database voor persistentie. Welk van deze onderdelen verschilt van de andere? Hoe. En waarom? Geeft dit nog security risico's.
4. Welke 3 problemen veroorzaakt de delay die Dave ervaart? Geef voor elk probleem aan of dit een probleem is voor Dave, Anna en/of het hele bedrijf.
5. Wat levert Dave eigenlijk precies op aan Anna? Is dit code of software? Wat is eigenlijk het verschil hier tussen?
6. Uit welke 2 componenten bestaat DevOps volgens het filmpje? (Niet 'Dev' en 'Ops'; kijk het filmpje!)
7. Welke van deze twee denk je dat belangrijker is? Waarmee moet je beginnen? Welke van de twee is het makkelijkst te adopteren?
8. Welk van deze twee besteden we de meeste tijd aan in de minor denk je? (En welke zouden we het meeste tijd aan moeten besteden vind je?)
9. Welke 3e item/onderdeel blijft impliciet? Kun je nog een 3e onderdeel verzinnen bij DevOps?
10. Met welke 3 soorten taken zorgt DevOps voor betere samenwerking en productiviteit?
11. Een van deze 3 taken (taaksoorten) heeft met workflows te maken. Wat bedoelt de verteller met workflows?
12. Iets verderop geeft het filmpje nog een lijstje van 3. Nu zijn het alle 3 'automatiseer' taken. Welk item is hier verschillend met het vorige lijstje van 3?
13. Stel je houdt met DevOps bijvoorbeeld een grote e-shop in de lucht (zoals je zelf zult doen in het beroepsproduct aan het eind van deze course). Dan kun je de zogenoemde 'conversie ratio' bepalen (conversion rate). Leg uit wat dit is, zoek eventueel op.
14. Wat heeft 'conversie' ratio met je antwoord op vraag 12 te maken?
15. Welk soort code schrijf je in de DevOps role meer dan in een Dev rol?

Les overzicht

• Bespreken stelling
• Behandelen huiswerkvragen
• Bespreken problemen bij weekopdracht 3
• Pauze
• 12Factor app principles (of 15 factor..): Duo ~~presentaties`` pitches (belangrijk voor de toets)
• Video 'The Difference Between DevOps and Continuous Delivery' (13 min) kijken en nabespreken (Farley, 2021)
• Checken leerdoelen

Als er onvoldoende tijd is voor video dan thuis zelf kijken en nu korte samenvatting door docent).

Les inhoud

Stelling:

"Requirements are the things that you should discover before starting to build your product." - Bron...?

12factor app principles

Opsplitsen in duo's en verdelen 12Factor principles.

Elk duo leest beide leden de introductie op de 12factor.net website. Het beantwoorden van onderstaande vragen onderling bespreken helpt je bij het geven van een presentie.

• Waarvoor zijn de 12factor principles? Gebruik in je antwoord de term 'software erosion' en leg uit wat dit is
• Wat is het verschil tussen SaaS, PaaS en IaaS, en welke is relevant voor 12factor principle en waarom?
• Geef een voorbeeld op waarin het principe van toepassing was uit je eigen ervaring als ontwikkelaar of operations werkzaamheden, of verzin er eentje, evt. met hulp van google of ChatGPT.

Leerdoelen Continuous Delivery

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kunt iets vertellen over 'Continuous Delivery' en de relatie met DevOps
• Je kent het belang van DevOps cultuur en mindset
• Je kent de 'three ways' van DevOps
• Je kent het Agile manifesto en enkele principes ervan en kunt uitleggen hoe DevOps in het verlengde daarvan ligt
• Je kunt verschillende stadia en vormen noemen hoe DevOps in een bedrijf is doorgevoerd
• Je kent de centrale rol van de CI/CD pipeline binnen DevOps en de aansluiting op versiebeheer
• Je snapt het principe van refactoren en de term technical debt
• Je kunt een (scripted) pipeline inrichten in Gitlab, GitHub of Jenkins (2.x)
• Je kent de 12factor app methodology en kunt toetsen of je software conform een bepaalde factor is

Bronnen

• Farley, D., Continuous Delivery (24-3-2021) The Difference Between DevOps and Continuous Delivery youtube.com Geraadpleegd november 2024 op https://www.youtube.com/watch?v=-sErBqZgKGs
• Fowler, M. (16-9-2008) Observed Requirement martinfowler.com Geraadpleegd november 2024 op https://martinfowler.com/bliki/ObservedRequirement.html
• Kim, G. Hiller, P (6-6-2020) DevOps Gene Kim Defines the 3 Ways of The Phoenix Project Jack Caine op youtube.com, geraadpleegd oktober 2024
• Rackspace Technology (12-12-2013) What is DevOps? - In Simple English YouTube.com, Geraadpleegd oktober 2024 op https://www.youtube.com/watch?v=_I94-tJlovg
• Sommerville, I. (2018) Engineering Software Products H10 Code management
• Wiggins, A. (2017) The Twelve-Factor App. 12factor.net. Geraadpleegd november 2024 op https://12factor.net

Week 4 - Orchestration

Lesoverzicht

• Les 1 (hele dag!) - Workshops Microservices & DDD
• Les 2 C4 & Continuous Documentation
• Les 3 RabbitMQ
• Les 4 SemVer
• Les 4 - Bespreken weekopdracht & Kubernetes 101

NB: De Kubernetes 101 les en praktische deel hierachter is in 2024 naar week 5 verplaatst.

"The portability and reproducibility of a containerized process [...] lets us move and scale containerized applications across clouds and datacenters.

We need tooling [...] to help automate maintenance, replacement and rollout of updates of the containers during their lifecycle!"

Docker docs - september 2021

Week 4 Opdracht

De week 4 opdracht in 2024/2025 is de Dev opdracht rondom RabbitMQ. Toepassen van Kubernetes theorie in praktijk zit in week opdracht 5, samen met monitoring/prometheus.

Verder wordt de weekopdracht opengezet, moet iedereen weer een duo partner hebben (en bij oneven aantal één drietal).

Over de gevormde teams verdelen we de 3 te gebruiken techniek om van de in vorige opdracht gebruikte Docker compose naar Kubernetes te gaan:

• Docker Stack vervallen
• Kompose
• Skaffold

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• DevOps-3 Je kunt werken met containers, gangbare software architecuren vertalen naar een container architectuur en de principes van container orchestration toepassen (Containerization)

• DevOps-2-3 Kan applicatie onderdelen 'containerizen' en onderling laten communiceren

• DevOps 2-4 Kent de rol van netwerken bij containers, en principes van een load balancer, firewall en proxy en relavante protocollen/standaarden

• MDO-DevOps-3 - Containerization/Orchestration "Je kunt werken met containers, gangbare software architecuren vertalen naar een container architectuur en de principes van container orchestration toepassen (containerization)"

• En de DDD en microservices leerdoelen n.a.v. Workshop InfoSupport. "Kent de basisprincipes van Domain Driven Design en kan deze toepassen en toetsen in DevOps code, configuratie en documentatie"

Workshop Event Driven Architectures (EDA)

Link naar sheets (Dag2Les.pptx) (private repo; met de slides en oefeningen)

Lesvoorbereiding

Als je stap 3 van het bestand “Exercises in Domain Driven Design” niet hebt voltooid, doe dan het volgende:

• Voltooi het domeinmodel voor de bounded contexts die essentieel zijn voor de gameplay.
• Zet de klassen van het domeinmodel om in code met je voorkeursprogrammeertaal. Focus op het maken van klassen en hun attributen, niet op het implementeren van spelregels.

Lesprogramma / Lesmateriaal

• Web Scale Architecture - Zie web-scale-patterns.pdf
• Chess Game DDD - Zie Git Repo

Leerdoelen

• Moet de student vier vormen van event-driven architecturen (Event Notification, Event-carried State Transfer, Event Sourcing, en CQRS) kunnen uitleggen en de verschillen ertussen benoemen. Daarnaast moet de student in staat zijn om de voor- en nadelen van elke vorm te onthouden en uitleggen.
• Aan het einde van de les moet de student het CAP-theorem kunnen uitleggen en de drie pijlers (Consistency, Availability en Partition Tolerance) beschrijven. De student moet kunnen toelichten waarom een gedistribueerd systeem maximaal twee van deze eigenschappen kan waarborgen.
• Aan het einde van de les moet de student het principe Design for Failure kunnen uitleggen, inclusief het belang van foutdomeinen (Bulkhead pattern). De student moet de 8 fallacies of distributed computing in algemene termen kunnen benoemen en begrijpen hoe deze valkuilen kunnen worden vermeden. Daarnaast moet de student het belang van het Circuit-breaker pattern voor snel falen in gedistribueerde systemen kunnen uitleggen.

C4 & Continuous Documentation

Deze les gaat over een van de 'Continuous Everything' zaken, namelijk Continuous Documentation. We kijken naar het C4 model van Simon Brown: Documentation for developers by developers! Daarna wat highlights van werk van HAN docent-onderzoeker Theo Theunissen rondom documentation in Continuous Software Development. Daarna naar Architecture Decision Records.

Maar eerst doen we een korte recap en aanvulling op InfoSupport's workshop over Domain Driven Design.

1. DDD + Microservices recap

Korte terugblik workshops over DDD respectievelijk microservices.

Samen bespreken DDD's strategic vs. tactical patterns, en korte recap van de 3 hoofd strategic patterns:. Na de bespreking snap je deze termen hopelijk en kun je dit uitleggen. Anders geeft de website infiniot deze korte definitie, en moet je een bron vinden die het uitgebreider uitleggen:

• *Ubiquitous Language – Een taal gestructureerd rond het domeinmodel en gebruikt door alle teamleden om alle activiteiten van het team met de software te verbinden.
• Bounded Context – Een beschrijving van de grens waarbinnen een bepaald model wordt gedefinieerd.
• Context mapping - Hoef je in deze cursus hoef je deze niet te kennen.

Deze laatste hangt wel vrij direct samenahngt met de andere twee, zoals een student al aangaf. En in de PitStop casus uit eindopdracht course fase zit een mooi voorbeeld van een Context Map waar je mee te maken krijgt.

Figuur 1: Ubiquitous betekenis (bron: Google translate)

Wellicht ken je al 'onion' of 'Ports and Adapters' architectuur. Hierbinnen zitten ook DDD tactical patterns als 'Repository' en 'Services' (met onderscheid tussen Application Services (technische glue) en Domain Services (business logica).

Figuur 2: DDD Tactical patterns: Onion architecture with 'lower level' DDD pattern (bron: Jordan Jordanov, J., Petrov P, 2023)

We zoomen in op de andere DDD tactical patterns:

Figuur 3: DDD Tactical patterns: Aggregate met Aggregate root en Entity vs Value object (bron: .NET Microservices Architecture for Containerized .NET Applications Figure 7-9. p. 203

Dit zijn meer 'implementatie in OO' gerichte patterns: Entity, Value Object en Aggregate. Een Aggregate geeft een idee van de minimale 'grootte' van een microservices definieren/beschrijven, Zoals je bv. leest in een online artikel van Microsoft Learn of Dave Taubler op Medium (edit 2024: helaas inmiddels achter paywal/abonnement):

"As a general principle, a microservice should be no smaller than an aggregate, and no larger than a bounded context. First, we’ll review the tactical patterns.” - Microsoft Learn (z.d.)

"... we [..] designed our microservices around Aggregates" - Dave Taubler (2020)

2. Continuous Documentation

Relevante vragen:

• Wat houdt 'Continuous Documentation' in?
• Wat is de relatie met 'Continuous Delivery' (en andere uit 'Continuous Everything'?)
• Kun je een praktijk voorbeeld van Continuous Documentation geven?
• Welke manieren van documenteren van Software ken je? (deliverables, methodes)
• Open vraag: Welke documentatie gebruik je binnen 'Ops werk'?

De 3 fasen van software documentatie volgens Theunissen (2021) (klik via 'Publicaties' onder https://theotheunissen.nl.

Lesopdracht: Maak een opsomming van veel vormen van documentatie die je als ICT'er in je opleiding/werkervaring bent tegengekomen. Verdeel deze daarna onder over de 3 fases;

1. Upfront: Acquiring knowledge
2. Development: Building knowledge
3. Delivery: Transferring knowledge

Zijn er ook types die in meerdere fases horen?

3. Het C4 model

De sheets van deze workshop.

Figuur 1: © Simon Brown, c4model.com

4. ADR's

Software Architectuur is het deel van de (software) design dat moeilijk te veranderen is. Je ontwerp leg je op verschillende niveaus vast met C4 en UML diagrammen en goede toelichtingen hierbij. Om verdere 'onderweg gemaakte' keuzes vast te leggen gebruiken we in deze minor Architecture Decision Records (ADR). ADR's zijn een heel belangrijk iets voor Software Architecten, maar ook Software Developers zoals beargumenteert in dit IEEE explore blog (2022)):

"ADRs’ greatest strength is their low barrier to entry. Since anyone on the team can write an ADR, everyone who wants can fill the role of software architect." - Michael Keeling (2022)

Hoe je deze keuzes vastlegt (documenteert) is weer een keuze op zich. Maar sowieso is het idee 'lichtgewicht' en direct bij de code in een tekst format, typisch markdown. Want de doelgroep is toch: mede developers/architects, kortom ICT'ers (en niet domein/business stakeholders, daar zijn andere docmenten voor). Hierbij is het handig een template te gebruiken. Om de keuze stress op dit niveau wat te beperken, en zo te kunnen focussen op concretere en relevantere keuzes in techniek en domein modelleren beperken we in deze minor de opties hiervoor tot twee:

1. Wellicht wel de best optie is een heel korte en krachtige variant van ADR's genaamd y-statements (DocSoc, 2020). Dit is feitelijk een enkele zin, maar hierin zit ook al een stuk 'alternatives':

2. Of je gebruikt het template van Nygard, één van de grondleggers, volgens een artikel van Michael Keeling (2022). Omdat een ‘decision’ (=beslissing) ook opties impliceert (anders kies je nergens tussen) nemen we hierin ook alternatieven op. In het template van Nygard zit geen apart kopje, maar zouden alternatieven dan onder kopje 'Decisions' moeten. Of je plaatst ze al direct in de Context' (zoals Nygard zelf deed in het artikel waarin hij ADR's introduceerde (Nygard, 2011). Maar in het kader van het 'single responsibility' principe voeg je ten opzichte van Nygard's template een extra kopje toe: `Alternatieven'. IN het kader van ['The pyramid principle'] (Minto, 2002) plaats je deze sectie ACHTER de 'Decision'

Binnen DevOps mag je echter afwijken van rigide standaarden, als er een goede reden is, het gaat immers om "Individuals and interactions over processes and tools" (Agile Manifesto, Fowler et al., 2001). DevOps over ligt immers in het verlengde van Agile (embrace change).

Dit is een heel stuk korter dan de volledige ADR in Nygard (Henderson, 2023) met kopjes:

• Status: What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
• Context: What is the issue that we're seeing that is motivating this decision or change?
• Decision: What is the change that we're proposing and/or doing?
• Consequences: What becomes easier or more difficult to do because of this change?

Zie voor een voorbeeld voor de PriemChecker casus de docs/ADR folder in de (PriemChecker repo) voorbeeld van standaard straks in het project.

"In the context of storing large prime candidates in our SQL database using Entity Framework Core, facing the need to accurately store numbers larger than the built-in SQL data types can handle, we decided for using a Value Converter to convert BigInteger to a string format for storage, and against using decimal or bigint storage formats, to achieve compatibility with extremely large numbers while maintaining database flexibility, accepting that this introduces performance overhead from conversion and adds complexity in the application logic."

Hieronder nog iets over de folderstructuur in dit project.

Folder structuur en toepassen Pyramid principle in documentatie

Qua folder structuur zet je de ADR's in folder /docs/adr en zet in zowel docs/ als docs/adr ook een README.md als 'landingspagina. De README.md onder adr geeft deze inleiding/leeswijzer en linkt naar alle ADR’s. Dit is ook de DoD (Definition of Done) voor ADR’s, namelijk het Nygard template format dat jullie hanteren (Henderson, z.d.) of Y-statements (Olzzio, 2023)

Ook kun je verbanden leggen tussen verschillende ADR's. Als je bv. in het begin van je project kiest voor dataopslag met SQL Server, en dit vastlegt in een ADR, en gaande het project, bv. vanwege geheugengebruik issues van SQL switcht naar meer light weight database als PostgreSQL kun je deze aan elkaar koppelen. Of juist naar MongoDB vanwege partitioning eisen, of wat dan ook. Ook heb je keuze om hierbij twee technologie specifieke ADR's te maken (e.g. ADR-SqlServer.md en ADR-PostgreSQL.md) of een enkele ADR, met een meer functionele/semantische naam Data-Persistence.md die je aanpast. In de paragraaf hieronder een voorbeeld van een te gebruiken tekst. Zoals hier aangeven gebruik het 'standaard format van Nygard, maar vul deze aan met 'Alternatives'. Of - als je het graag zo kort mogelijk houdt - kijk eens naar 'y-statements' van Olzzio (2023).

Quiz

Test je kennis over continuous documentation en C4 met deze korte multiple choice quiz.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kunt uitleggen wat Continuous Documentation is en hoe het zich verhoudt tot Continuous Delivery.
• Je kent praktijkvoorbeelden van Continuous Documentation en kunt verschillende manieren van documenteren van software beschrijven.
• Je kunt het C4 model uitleggen en beschrijven hoe het helpt bij het documenteren van softwarearchitectuur binnen DevOps teams.
• Je kent twee manieren van architectuur beslissingen vastleggen met ADR's die je in het DevOps project gaat gebruiken
• Je kent de belangrijkste strategic DDD patterns zoals Ubiquitous Language, Bounded Context, en Context Mapping, en kunt het onderscheid uitleggen tussen strategic en tactical patterns.
• Je kunt voorbeelden geven van tactical DDD patterns zoals Entity, Value Object, en Aggregate, en weet dat aggregates een indicatie geven van minimale grootte van microservices.

Bronnen

Hier (nogmaals) de bronnen gebruikt op deze pagina in APA format.

• Brown, S. (z.d.). C4 model. Geraadpleegd op 23 september 2024 op https://c4model.com/
• Doc Soc (7-5-2020) Y-Statements - A light template for architectural decision capturing. Medium.com. Geraadpleegd september 2024 op https://medium.com/olzzio/y-statements-10eb07b5a177
• Google. (z.d.). Ubiquitous language betekenis via Google Translate. Geraadpleegd op 23 september 2024 op https://translate.google.com/?hl=nl&sl=en&tl=nl&text=ubiquitous&op=translate
• Jordanov, J., & Petrov, P. (2023). Domain Driven Design Approaches in Cloud Native Service Architecture. Geraadpleegd op 23 september 2024 op https://www.researchgate.net/publication/375982003_Domain_Driven_Design_Approaches_in_Cloud_Native_Service_Architecture/
• Keeling, M, (20 June 2022). Love Unrequited: The Story of Architecture, Agile, and How Architecture Decision Records Brought Them Together IEEE. Geraadpleegd dec 2023 op https://ieeexplore.ieee.org/document/9801811
• Microsoft. (z.d.). Implementing Value Objects with DDD. Geraadpleegd op 23 september 2024 op https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/implement-value-objects
• Theunissen, T. (2021). Csimq: Continuous Software Development Documentation Artifacts. Geraadpleegd op 23 september 2024 op https://theotheunissen.nl/wp-content/uploads/2022/09/csimq.pdf
• Parker Henderson, J. Decision record template by Michael Nygard. Github.com geraadpleegd september 2024 op https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/locales/en/templates/decision-record-template-by-michael-nygard/index.md
• Using tactical DDD to design microservices Microsoft Learn. Geraadpleegd september 2024 op https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd
• de la Torre, C (2023) .NET Microservices Architecture for Containerized .NET Applications v7.0. Microsoft Coorporation. Geraadpleegd september 2023 op https://github.com/dotnet-architecture/eBooks/blob/main/current/microservices/NET-Microservices-Architecture-for-Containerized-NET-Applications.pdf
• Minto, B. (2002) The pyramid principle : logic in writing and thinking 3rd edition, Financial Times Prentice Hall

Dev workshop 4 - RabbitMQ

Lesmateriaal voor deze workshop is te vinden in de repo workshop-rabbitmq in de besloten gitlab groep rabbit-mq (alleen voor minor studenten, je moet ingelogd zijn in (AIM hosted) GitLab omgeving).

Quiz

Test je '101 kennis' over Kubernetes met deze korte multiple choice quiz:

Leerdoelen

• Je kunt uitleggen wat een message broker is en de rol beschrijven van RabbitMQ in verbeteren van 'loose coupling' van systemen.
• Je kunt het verschil beschrijven tussen verschillende messaging patterns, zoals work queues, publish-subscribe, routing en topics en gegeven een situatie/toepassing aangeven welke het geschiktst is.
• Je kunt de componenten van het AMQP-protocol beschrijven, zoals exchanges, queues, bindings en routing keys, en uitleggen hoe ze samenwerken in RabbitMQ.
• Je kunt uitleggen hoe RabbitMQ berichten routeert op basis van binding keys en routing keys.
• Je kunt van de verschillende types exchanges in RabbitMQ in ieder geval fanout uitleggen en bijbehorende use-cases benoemen.
• Je kunt een real-world analogie geven voor de werking van RabbitMQ, bijvoorbeeld door het te vergelijken met het sorteer- en bezorgproces van een pakketbezorgdienst.

Semantic Versioning

Figuur 1: Semantic versioning (bron: Surjit Bains, CC BY-SA 4)

NB Dit is in 2024 in week 4 geplaatst als zelf studie om voldoende tijd te hebben voor kubernetes in week 5. Kubernetes zit op het moment van schrijven op versie 1.28.x. K8s gebruikt semver: semantic versioning

"Kubernetes versions are expressed as x.y.z, where x is the major version, y is the minor version, and z is the patch version, following Semantic Versioning terminology. - kubernetes.io

Opdrachten/zelfstudie

1. Lees over Semantic Versioning op semver.org zodat je het begrijpt
2. Welke onderdelen je wel of niet leest, mag je zelf bepalen, maar zorg dat je bij plaatje in Figuur 1 een verhaal kan vertellen over wanneer je welke van de 3 delen van een semver versie moet ophogen
3. En beantwoord ook waarom de term 'semantisch' in de naam semver zit
4. Denk eens na op welke zaken in een DevOps project je allemaal versies kunt geven.

Tijdens het project is semver ook een goede keuze. Je hebt echter de vrijheid om een eigen versienummer systeem te gebruiken. Zolang je dit documenteert/ernaar verwijst. Én er ook een goed idee achterzit. Dus bijvoorbeeld niet een 'anti naming pattern' zoals WendtVer die voor kenners wel vermakelijk is om te lezen.

"Let WendtVer provide you with a “fun” way to release and upgrade packages without having to think, saving you time and thinking."

Je mag er zelf over nadenken of alleen een git commit hash gebruiken als versienummer een goed idee is... :).

Als je een toepassing wilt kijken van semver die in een groot project ook erg handig is kun je eens kijken naar `conventional commits':

"[Conventional commits] dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages." - https://www.conventionalcommits.org/en/v1.0.0/

TL; DR

De DDD term 'ubiquitous language' is van belang voor het checkpunt 'IR-201 Gedeeld informatiemodel' uit het CDMM. Dit staat uitgelegd onder de categorie 'Information and reporting'. Zie voor uitleg hiervan de beschrijving op pagina over 'DevOps concepten'. Zoals daar uitgelegd gaat het in CDMM checkpoint 'shared information model' vooral over informatiemodel van het software ontwikkel proces. In plaats van het domeinproces in het domein van je software zelf over gaat.

De term 'domein' is ook een verwarrende term, aangezien soms ook ICT zelf, en dus 'software ontwikkelen' een domein is. Namelijk het domein waar je les in krijgt op het HBO ICT. Het kunnen analyseren van andere domeinen waarbinnen je automatiseert is een van de competenties nodig om goed te kunnen werken in het ICT domein. Binnen dit ICT domein is een belangrijk concept dat van 'semantic versioning': semver. Dit geeft algemene richtlijnen over de betekenis van versienummers van software. Binnen een specifiek domein kun je vervolgens met semver je concrete software ook concrete semver versies toewijzen, waarbij je dan in kaart brengt welke features of bugfixes een bepaalde versie bevat. In termen van de concrete functionaliteit die een applicatie heeft. Maar ook de software tools die je zelf als developer gebruikt, en eindgebruikers geen weet van (hoeven te) hebben kan semver versies hebben.

Quiz

Leerdoelen

• Je kunt uitleggen wat semantic versioning inhoudt en waarom het nuttig is in softwareontwikkeling.
• Je kunt het verschil uitleggen tussen de drie onderdelen van semantic versioning en aangeven welk onderdeel je verhoogt in specifieke situaties.
• Je kunt uitleggen hoe je semantic versioning toepast om compatibiliteit te waarborgen tussen verschillende versies van een project.

Kubernetes 101

NB In 2024 gaat deze les NIET door, en zit onderstaand huiswerk bij workshop Alliander van de maandag erop en de daarin niet behandelde theorie uit deze les behandelen we in de Kubernetes 102 les de dinsdag erop.

Deze les kijken we naar de 'Kubernetes architectuur', en alle componenten van Kubernetes. Formeel Kubernetes 'resources' genoemd, zoals Cluster, Node etc. De les begint echter met een recap van de vorige les en uitstapje over semantic versioning. En hieronder eerst het voorbereidende huiswerk.

Huiswerk

Doe het volgende huiswerk. Dit zijn 2 stukken documentatie over 'orchestration' van Docker en 2 korte opdrachten die hierop doorgaan:

1. Lees de Docker: Orchestration, get started... documentatie en zet lokaal Kubernetes aan in Docker Desktop volgens de instructie (je hoeft NIET Docker Stack aan te zetten, dat is deprecated)
2. Bekijk de 1e 12 minuten van deze presentatie van Edwin van Wijk (medewerker InfoSupport).
   • Als je liever leest dan video's kijkt neem de onderdelen van de 'overview' van de Kubernetes docs op kubernetes.io door,
   • Vanaf 2:11 begint het stuk over Kubernetes, na een intro over Docker, maar vanaf het begin kijken is wellicht wel zo relaxed
   • Zorg dat je ieder geval de concepten Pods, Deployments en Services duidelijk hebt. Als de video hiervoor te kort/high level is; lees dan de kubernetes docs, of er is ook deze wat uitgebreidere versie om ook intro te krijgen in Pitstop en vergelijking K8S en Docker compose (vanaf ca. 6:00 tot ergens 30 a 40 minuten. Je kunt sowieso stoppen als Edwin Service Mesh gaat behandelen (dat zou mooi onderzoeksonderwerp zijn voor week erna, als je dit interessant vindt).
   • De Kube proxy zorgt dat een pod via network bereikt kan worden en Kubernetes higher level concepten als een NodePort kan realiseren.

A. Neem Figuur 1 voor jezelf op papier over, en breidt deze tekening met met concepten Cluster, Nodes en Pods uit met de overige Kubernetes resource types. Voeg hierin ook de ReplicaSet toe en lees hiervoor de volgende bron over ReplicaSets op website bmc.com.

- Merk op dat in deze overview de *Kubelet* voorkomt i.p.v. een pod. Een Kubelet is te zien als 'de Ops kant' van een Pod. Een Kubelet is een daemon programma dat draait op een server en van de server een K8S node maakt. Meestal gaat deze deel uitmaken van de *data plane* zodat de K8S *control plane* node(s) hier een Pod kan gaan draaien. Vanuit de 'Dev' kant heb je liever de pod als abstractie, dan kun je dit 'extra [niveau van indirectie](https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering)' negeren. Maar zeker een mogelijk onderzoek in week 6 om onder de moterkap te kijken naar schalingsmogelijkheden van pods of de Ops side van Nodes:
  - Horizontal Pod Autoscaling *HPA)
  - Hoe de kubelet een PodSpec te sturen.
  - Hoe een Kubelet meer dan één pod beheren, zogenaamde 'side car pods'

Figuur 1: Diagram van een Kubernetes cluster.

B. Kijk naar Figuur 2 en klik er zo nodig op voor een grotere versie.

• Maak een schema/lijstje met opdeling van de Kubernetes commands's in de 'imperatieve' en 'declaratieve' commando's.
• En doe kort onderzoek naar de achtergrond hiernaar. Stel bv. ChatGPT een vraag hierover, en valideer wat je terug krijgt kort door te googlen naar andere bronnen.
• Bijvoorbeeld een relevante stackoverflow post.

Figuur 2: Kubernetes: imperatieve vs declaratieve commando's in Kubernetes

Kubernetes Architecture

Figuur 3 geeft weer een beeld van de K8S resources in de K8S architectuur.

Figuur 3: Kubernetes Resources

Dit zijn er best veel, dus staan we er even bij stil. Gelukkig waren de lessen over Docker (van vorige week) wel een springplank voor veel concepten. Probeer voor je zelf alle objecten op te halen en op te schrijven. Highlight hieronder de tekst om antwoord zichtbaar te maken.

...

Figuur 3: (Een deel van) ChatGPT 4's poging tot een overzicht als Mermaid klassediagram.

Quiz

Test je '101 kennis' over Kubernetes met deze korte multiple choice quiz:

Leerdoelen

• Je kunt uitleggen wat Kubernetes is en dat je het gebruikt voor containerorchestratie.
• Je kent het onderscheid in Kubernetes tussen control plane en data plane.
• Je kunt het verschil uitleggen tussen de node types binnen Kubernetes (master en worker nodes) en hun rol binnen de cluster.
• Je kent Kubernetes resources zoals Pods, ReplicaSets en Deployments en kunt beschrijven hoe deze met elkaar verbonden zijn en welke functie ze vervullen.
• Je herkent de voordelen van declaratieve versus imperatieve Kubernetes commando's en kunt uitleggen hoe je deze toepast in verschillende scenario's.

Week 5 - SlackOps (monitoring)

Lesoverzicht

• Les 1 - Alliander Workshop: K8s & GitOps
• Les 2 - Kubernetes 102
• Les 3 - Prometheus + Chaos Engineering
• Donderdag: 2e deeltoetsen Dev & DevOps
• Les 4 - Workshop Prompt Engineering & Onderzoeksopdracht

Les 5-1 Alliander workshop: K8S & GitOps

Alliander gastles

Les 5-2 Prometheus/PromQL en Chaos engineering/Load testing

Kijk verder naar les over Prometheus en chaos engineering.

Les 5-3 Todo

Todo.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• MDO-DevOps-5 - Slackops "Je kunt goede logging en monitoring realiseren in verschillende omgevingen en zorgen voor applicatiespecifieke rapportages"
• Ops-2-1 Je kent de principes van chaos engineering en de toegevoegde waarde hiervan

Workshop Alliander - DevOps bij Alliander: ArgoCD & GHA & Pax

Het bedrijf Alliander uit (o.a.) Arnhem komt in onze minor een workshop geven over 'DevOps bij Alliander'!

Huiswerk

De informatie uit deze workshop overlapt deels met de Kubernetes 101 les. Maak het huiswerk/de voorbereiding daarvan.

Alliander: netwerkbeheer

Dit zijn de slides van de presentatie van Alliander:

• DevOps bij Alliander (2024)

Alliander doet netbeheer, maar is effectief ook een ICT-bedrijf met 100-en ICT'ers in dienst. Slimme ICT is een belangrijk onderdeel van hun bedrijfsvoering en absoluut noodzakelijk in het kader van de energietransitie, wat in de huidige maatschappij erg belangrijk is.

Alliander: ICT

Kortgezegd gebruikt Alliander ook het onderdeel GitOps uit DevOps en hierbij van tools als Kubernetes, GitHub Actions en ArgoCD.

• ArgoCD is een tool voor GitOps volgens een 'pull based model' (voor Continuous Deployment)

Figuur 1: GitOps

Quiz

Test je kennis na deze workshop van Alliander met deze korte multuple choice quiz.

Leerdoelen

Het doel van de workshop is dat je een goed beeld hebt van hoe Alliander bij hun praktijk DevOps in de praktijk invult. Dus welke standaard tools en best practices Alliander gebruikt.

• Je kunt uitleggen hoe Kubernetes en Helm worden gebruikt voor het beheren en deployen van applicaties binnen Alliander.
• Je kunt beschrijven wat GitOps inhoudt en uitleggen hoe het wordt gebruikt om infrastructuur te beheren met Git als single source of truth.
• Je kunt de werking van een GitOps Operator zoals ArgoCD uitleggen en begrijpen hoe deze wordt gebruikt voor continuous delivery.
• Je begrijpt hoe het CI/CD proces bij Alliander is ingericht met GitHub Actions en ArgoCD en kunt het belang hiervan toelichten.
• Je kunt uitleggen hoe AWS Elastic Container Registry (ECR) wordt gebruikt om container images op te slaan en beheren zoals voor software updates of container retentie.

Kubernetes 102

NB In 2024 behandelen we in deze les ook nog niet eerder behandelde onderwerpen uit de Kubernetes-101 les

Deze les geeft Kubernetes verdieping en dient om aan de slag te kunnen met je eigen Kubernetes Rancher cluster onder aimsites.nl en hierop een kleine microservice applicatie te kunnen runnen (PitStop).

Huiswerk/voorbereiding

Dit is het huiswerk voorafgaand aan de les:

1. Neem als recap van de vorige les het artikel Kubernetes 101 door
2. En ook de korte blog post 'Difference between a load balancer and an ingress'
3. Neem high level de 3opties door voor migratie uit Docker compose in artikel van Milind Chavan (2021)
4. Lees de documentatie over Kompose op de Kubernetes docs.
5. Beantwoord onderstaande 8 huiswerkvragen. Zoek o.b.v. dingen die hierin onduidelijk zijn zelf relevante stukken uit de volgende bronnen (eigen keuze/leerwegonafhankelijk)
   • de Kubernetes documentatie (kubernetes.io) over meer gedetailleerde werking van Deployments, Replicasets, Ingress en Services.
   • Of meldt je aan voor de gratis (fremium) Linux Foundation course over Kubernetes en neem hoofdstuk '8. Kubernetes building blocks en '10 Services' door.

Huiswerkvragen

1. Noem 3 opties om te upgraden vanaf docker compose naar Kubernetes
2. Noem een voordeel van elk van deze 3 opties
3. Kun je op productie ook Docker en Docker compose gebruiken? Noem minstens 1 reden waarom je dit zou willen, en 2 waarom niet.
4. Wat betekent "Pods are used as the unit of replication in Kubernetes."
5. Wat betekent 'round robin'? Google het zo nodig (staat niet in de bronnen) leg het uit
6. Wat is DNS en hoe gebruikt Kubernetes dit?
7. Op welke (wel/andere) behandelde 'resource' lijkt een Kubernetes DaemonSet?
8. Zelfde vraag voor de (verouderde) K8S resource ReplicationController: a. met welke resource(s) hangt deze samen? b. waarom is de ReplicationController gedeprecate? vind in bron, of vraag bijvoorbeeld aan ChatGPT en evalueer diens antwoord en zorg dat je het zelf snapt/kan reproduceren

Les

Kubernetes (K8S) is een te groot onderwerp om geheel in één week te kunnen behandelen. Hier zou je ook een hele minor mee kunnen vullen.

De bedoeling is dat je basis K8s Architectuur en K8S componenten en concepten kent en hier mee om kunt gaan. Zodat je m.b.v. kubectl en extra benodigde vaardigheden tijdens opdracht en project relatief snel kunt uitzoeken met behulp van deze 'kapstok van kennis' die je al hebt.

In deze les kijken we naar:

• Terugblik Kubernetes architectuur (vragen vorige lessen)
• Het YML format en de relatie met JSON
• K8S advanced onderwerpen 'Ingress'
• K8S advanced onderwerp 'etcd' (en de relatie met High Availability clusters)
• Optioneel: het begrip 'Quality of Service' in algemeen, en specifiek in K8S in verband met mogelijk onderzoek.
• Workshop ArgoICT over Kubernetes (en K8S 'workloads')

1. Lesopdracht/-uitstapje: JSON vs YAML

Bekijk de website https://www.json2yaml.com/ en experimenteer hiermee. Zorg dat je duidelijk krijgt de link tussen JSON en YAML.

2. Lesvragen .yml

1. Is YAML ook JSON?

2. Hoe ziet een JSON array eruit bij omzetten naar YAML?

3. Hoe ziet een JSON object eruit? Wat is het verschil en overeenkomst met een array?

4. Maak een YAML bestand met een lijst van namen van jezelf en 3 studenten die om je heen zitten. Zet erna in het bestand ook de informatie over jezelf qua:

   • 'lievelingskleur'
   • 'favoriete film'
   • 'hobby'

5. Vraag ook een van de 3 klasgenoten deze 3 'properties' en vul in

6. Ken je nog meer talen/formats die onderling zo'n zogenoemde 'superset' zijn van een andere taal/format? Schrijf op welke. Wat is het voordeel?

3. Nog 2 K8S onderwerpen: Ingress en etcd

Interessant én relevant stuk theorie is de werking van etcd, het gedistribueerde opslagsysteem waar K8S de eigen config opslaat. En wat ook een beeld geeft van kwesties rondom 'database sharding' en ook 'clustering' en 'voting. Bekijk deze korte intro:

We bekijken samen de video Kubernetes Ingress in 5 mins - Sai Vennam, IBM (5:40 minuten)

• What is etcd? - Whitney Lee, IBM (6 minuten)

Lesvragen Ingress en etcd

• Wat hebben K8S Ingress en etcd met elkaar te maken? (if any)
• Wat is het verschil tussen een Ingress en een Service?
• Bedenk zelf een toetsvraag over Ingress en zet in Teams
• Wat is een HA cluster in K8S?
• Wat heeft het aantal met het Raft voting systeem te maken?
• Wat is een 'etcd. member' en zit deze in control plane of data plane?

Optioneel: Quality of service in K8S

Een opstapje naar 'advanced Kubernetes' is wel het concept 'Quality of Service' (QoS) en implementatie en werking hiervan in Kubernetes.

Dit zou een mooi onderzoek zijn voor wie deze meer 'Ops side of things' wil verkennen.

Workshop "K8S op Rancher - Kubernetes een beetje praktisch" - Argo ICT

Het bedrijf Argo ICT uit Arnhem, met oud HAN student Murat Castermans geeft een hands-on uitleg bij het gebruik van een Rancher cluster voor de laatste opdrachten in de course fase.

Argo ICT moet je niet te verwarren met de vaak in het blok 2 gebruikt project te gebruiken tool Argo CD :). Argo ICT regelt de complexere ICT benodigheden voor HAN ICT en AIM, maar hebben ook andere klanten.

Samenvatting presentatie

Hier de link naar de presentatie (Google Slides)

Enkele quotes/samenvatting

Kubernetes is 'meer dan alleen maar schaalbaar' "Je hebt iemand die continue over je schouders meekijkt".

• Aantal issues tackled K8S zelf, heeft bv. probes voor detecteren van memory leaks, zodat je 's nachts niet wakker wordt gebeld.
• Je hoeft geen rekening houden met allerlei zaken aan de achterkant, zoals het configureren van Nginx, of OS specifieke zaken.
• Je hebt minder last van vendor lock-in. Zolang het maar 'Certified Kubernetes' is.

Soorten workloads in K8S

Quote uit de Kubernetes docs over 'workloads'

"A workload is an application running on Kubernetes. [...] Kubernetes provides several built-in workload resources:

(Uit de sheets van Murat):

• Deployment - Alles stateless, maakt niet uit welke node en of er storage is, makkelijk schalen, bv. een JavaScript front-end in een Nginx container
• StatefulSet - Wel storage, geisoleerd van andere storage, bv. voor database server
• Daemonset - K8S zorgt dat deze 'service' elke Node zorgt , bijvoorbeeld voor logging services (zoals FlentD)

Verdere highlights

K8S kent 3 soorten probes: Startup, Readiness (traffic) en Liveness (kill)

Gebruik voor testen op je eigen K8S cluster op aimsites een port forward, i.p.v. een NodePort setting (zoals je op localhost wel doet).

RWO = 'Read Write Once', wordt niet getoetst, wel interessant voor onderzoek evt. (access modes van K8S PersistentVolumeClaim)

Quiz

Test je kennis met deze korte multiple choice quiz.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kunt uitleggen wat de rol van Pods is als replicatie-eenheid in Kubernetes.
• Je begrijpt hoe Kubernetes Ingress werkt en hoe het verschilt van een Service.
• Je kunt uitleggen hoe een HA cluster werkt in Kubernetes en waarom minstens drie master nodes vereist zijn voor etcd consensus.
• Je kent de voordelen van migreren van Docker Compose naar Kubernetes en weet hoe tools zoals Kompose en Skaffold hierbij helpen.
• Je kunt de functie van een DaemonSet in Kubernetes uitleggen
• Je kent het voorbeeld van de ReplicationController uit de K8S die is gedeprecate en vervangen door ReplicaSet als voorbeeld van verbeteringen en verandering in Kubernetes historie
• Je kunt het verschil tussen JSON en YAML uitleggen aan de hand van hun relatie en voorbeelden en kan uitleggen waarom men .yml vaker voor K8S config gebruikt

Prometheus & Chaos engineering

NB Deze les vervalt in 2024 voor dinsdagmiddag 31 september. Vanwege drukte, de toets donderdag en verkortte laatste (course) weekopdracht. Deze les komt in week 6 kort terug als 2 goed onderwerp voor een eigen onderzoek en/of toepassing in PitSop BP/eindopdracht.

Vandaag 2 aparte onderwerpen: monitoring en statistieken via Prometheus en Grafana. En een 'build for failure' aatitude via Chaos engineering in K8S met de tool Chaos mesh.

Huiswerk/voorbereiding Chaos Engineering

• Zorg dat je begrijpt wat Chaos Engineering is én hoe je dit bereikt (Chaos Monkey, bv. link met 'design for failure' uit Event Driven workshop)
• Lees over Chaos Mesh
• Als het goed is ken je al het concept 'shift left', neem deze blog door over het concept 'shift right'
• Optioneel: Doe de 3 stappen van de Quickstart van open source Load test tool K6
• Krijg zelf overzicht van de Prometheus architectuur (zie figuur 1) door de website van Prometheus zelf door te nemen: prometheus.io.

Chaos Mesh

Figuur 1: Chaos Mesh

Figuur 2: Shift left vs shift right

Huiswerkvragen

• Schrijf voor jezelf op wat 'shift left' betekent. Beantwoord in ieder geval:
  • waarom term 'left'?
  • wat shift je?
  • betrek ook het plaatje van software development continuum (of DevOps infinity loop)
• Zelfde voor 'shift right': Wat betekent shift right?
  • Betekent 'shift right' dat je test in productie?
  • Wat heeft shift right' met SlackOps te maken?
  • Kun je een load test ook op een test omgeving doen? Wat is er dan nodig?

Uitstapje: The founder

Figuur 3: 'Founder trailer'

Lesvraag: Wat heeft deze video met DevOps te maken? Link ook aan het concept 'shift right'.

Chaos Engineering in PitStop

Figuur 3: Video: Stukje Chaos engineering in PitStop; demo van Edwin van Wijk

• Welke tools gebruikt Edwin van Wijk om Chaos Engineering principe toe te passen (het YouTube filmpje start bij stuk over 'Chaos Engineering' op 41 en een halve minuut. Misschien ). Bij welke van de 5 weekthema's uit de minor hoort elke?

• Welk onderzoeksmethode hoort bij een load test? (if any)

  • In welke onderzoeksruimte zit deze methode?
  • Wat is het verschil tussen een load test en een performance test? (if any)
  • Vindt een alternatieve tool voor K6, schrijf kort verschil in features tussen de twee (nadeel en voordeel t.o.v. elkaar)

Prometheus

Week opdracht 5 bevat het maken van custom metrics in je applicatie en het verzamelen (scrapen) hiervan met Prometheus.

Figuur 1: Prometheus architectuur (bron: prometheus.io)

In deze laatste onderwijsweek testen we meer je eigen attitude.

Attitude

• je bent nieuwsgierig, en vindt zelf geschikte bronnen (je hebt deze minor zelf gekozen, en gaat volgende week ook onderzoek doen)
• je werkt zelfstandig (je gaat na de minor afstuderen)
• kunt *samenwerken ('DevOps is cooperation').
• je bent pragmatisch (je pakt een nuttige rol in de groepsopdracht, bepaalt een einddoel en houdt deze in de gaten)

Vanuit deze attitude zorg je dat een aantal dingen kent (kennis op doet) en kunt (vaardigheden aanleren en oefenen).

Kennen:

• de Prometheus architectuur
• Belangrijke termen: metrics, metrics server, promql, visualizer, service discovery, time series en scraping.
• Ook weet je hoe samenwerking Prometheus is met Grafana of andere broodnodige visualisatie tools als de ELK stack (omdat Prometheus NIET zelf visualisatie doet; zie figuur 2.)

Kunnen:

In de weekopdracht moet je

• enkele algemene metrics tonen
• maar ook applicatiespecifieke metrics.

Figuur 2: Prometheus uitgebreide architectuur (inclusief visualisatie tool als Grafana; bron: DevOpsSchool.com)

Bronnen

TODO: netjes volgens APA.

• Basis architectuur https://prometheus.io
• Uitgebreide architectuur... Geraadpleegd op 3-11-2023 op https://www.devopsschool.com/blog/what-is-prometheus-and-how-it-works/

Deeltoetsen 2

De 2e twee toetsen (Dev + DevOps() nemen externe surveillanten centraal af op 3 oktober, zie Osiris voor locatie. Hieronder tijdsinfo, en helemaal onderaan ook oefentoetsen en iets over de stof.

Disclaimer: Onderstaande informatie is voor het gemak en met enige zorg samengesteld. De officiele toetsregeling van de HAN gaat uiteraard altijd voor, mocht hier iets niet kloppen vergeleken met die regels van CTO (Centrale Toets Organisatie HAN). In het OS/OER staat echter weinig specifieks maar zie bv deze pagina op han.nl.

Indicatief tijdschema

• 9:00 Begintijdstip TheorieToets Dev en DevOps (zelf kiezen welke eerst, max 30 minz (of 37,5 of 45))
• 9:30 Eerste mogelijkheid lokaal te verlaten (en evt. alsnog binnenkomen voor laatkomers)
• 10:00 Einde
• 10:30 Einde Extra tijders
• 10:45 Toetslokaal einde

Combi toetsen

In iSAS staan beide toetsen op het zelfde moment, maar dit is omdat de toetsen veel korter zijn dan het toetsmoment. Circa een half uur. Voor mensen die 'Extra Tijd' regeling hebben (aanvragen via Osiros) dus 25% of 50% langer, dus dan ca./max 3 kwartier. Kom niet te laat, want in verband met de 'rust' mag je daarna pas bepaald tijdstip de toets in op het wisselmoment (typisch een half uur na start toets, dus bv. 9:30 als 9:00 de toets start.)

Tussendoor uitloggen uit Schoolyear

Je kunt zelf de toetsen starten in Ans. Bij start van de toets komt de Schoolyear koppeling, zodat je in een afgesloten omgeving de Ans toets maakt. Zorg dat je deze al installeert bij een oefentoets, of via proberen, en laat hem dan staan. Dit scheelt je wat installatie tijd.

Max. tijd per toets ingeregeld in Ans

Voor de toets is de gehele toetstijd ingesteld qua begintijd, eindtijd, dus 9:00-10:30. Maar voor elke toets is wel een maximale tijd ingesteld. Je moet ook minimaal een half uur in het lokaal blijven zitten, dus mocht je beide toetsen kunnen maken binnen een kwartier, dan moet je nog even geduld hebben. Als je slechts 1 toets komt maken, bv. bij een herkansing, geldt OOK dit half uur.

Merk wel op dat je einde toets, na inleveren en afsluiten ook echt de rode 'EXIT' knop moet gebruiken in Ans, om zo ook de Schoolyear sessie te beeindigen. Voor de volgende toets start je dan Schoolyear weer opnieuw op.

Hoewel je BINNEN de Schoolyear browser in Ans soms ook wel de andere toets kunt zien om op door te klikken, leidt Schoolyear — als je dat doet — je dan alsnog weer terug naar de toets waar je net uitkomt. Dit kan behoorlijk verwarrend zijn. Dus sluit Schoolyear dus einde toets af af, en dan werken linkjes wel zoals je verwacht.

Oefendeeltoets Dev 2/2

Edit minor 2024/'25: De oefenquizzes op specifieke pagina's zijn meer bijgewerkt en hebben minder oververtegenwoordiging van Kubernetes vragen dan onderstaande pdf's (hoewel deel van K8S vragen nog wel relevant zijn):

• Oefendeeltoets Dev 2 (5 minuten)
• Oefendeeltoets DevOps 2

De toetsen gaan over alle stof in week 3 t/m 5 in de course DevOps respectievelijk Dev.

Hieronder voor 2024 een korte samenvatting. Maar het is handiger om zelf een samenvatting te maken tijdens het doornemen/herhalen van de stof uit online materiaal, gelinkte bronnen en slides, etc.

Neem ook de leerdoelen van de weekthema's en lessen door en controleer dat je hierover de kennis ('kent') of vaardigheid ('kan') hebt, door een verhaaltje te vertellen.

Dev toetsstof 2024

• Micro Frontends
• C4 & Continuous Documentation
• RabbitMQ

DevOps toetsstof 2024

• Continuous Delivery (incl. 12factor, IAAS vs PAAS vs DevOps three ways e.d.)
• Domain Driven Design (DDD) + Webscale + Microservices (MSA)
• Behaviour Driven Design (BDD)
• Event Driven Architectures (EDA)
• SemVer
• Orchestration/Kubernetes (etcd)
• CDMM (niet uit hoofd, maar CDMM categorieen en checkpoints hieronder wel herkennen en kunnen uitleggen/toepassen)
• SlackOps (Chaos engineering)

Toetsregels

Cesuur 70%: max 12 fout voor voldoende (5,5).

• Eén punt voor iedere 'multiple choice' vraag (tenzij anders aangegeven).

  • Bij multiple choice is slechts 1 antwoord goed (of 1 antwoord is 'het beste').
  • Voor open vragen is het aantal punten aangegeven.

• Er zijn geen hulpmiddelen teogestaan zoals boeken, spiekbriefjes, websites of communicatiemiddelen toegestaan.

  • Je mag alleen 1 browser open hebben met 1 tabblad (namelijk die met daarin deze online toets)!
  • Voor de start van de toets graag je rugzak of tas met je telefoon, smartwatch en/of andere devices voorin de klas leggen.
  • Evt. gebruikt kladpapier moet je bij het verlaten van de klas ook inleveren.

• Je mag het lokaal verlaten pas na de helft van de toetstijd, en dan laptop en rugzak achter laten in de klas.

• Mensen met 'extra tijd' regeling kunnen max 50% extra tijd krijgen. I.v.m. bepertke lestijd en nabespreking gaat dit wel ten koste van eventuele pauzetijd tussen 2 toetsen door.

• Bij Digitale toetsen in Ans gaan via de Schoolyear safe browser

  • Sluit de toets na het starten NIET meer af, dit ziet Schoolyear als fraude, en dan sluit deze je buiten

• De digitale toets is 'Bring your own device', je moet Windows of macOS draaien (dus geen Linux, regel dan 'dual boot' of vraag anders tijdig een leenlaptop aan bij de HAN (dit kan via Osiris))

Workshop Onderzoeksplan + Prompt Eng.

In deze workhop hebben we het over prompt engineering, en stel je een onderzoeksplan op.

Inleiding - Over onderzoek en Prompt engineering

Bij HAN ICT (AIM) vinden we het erg belangrijk dat je onderzoek doet. En een onderzoekende houding hebt. Dit is zelfs noodzakelijk, omdat de ICT sector zo in beweging is, dat je ook na je studie zult moeten blijven bijleren (Leven Lang Ontwikkelen). De opgedane kennis en vaardigheden uit je studie zijn wel een basis en een kapstop waar je nieuwe kennis aan kunt ophangen, en vaardigheden kunt verfijnen. Heel belangrijk hierbij is dat je de juiste vragen kunt stellen, juiste bronnen kunt vinden en de juiste methoden kunt gebruiken.

Wel richten we ons op toegepast onderzoek in plaats van theoretisch onderzoek. Dit laatste gebeurt meer op universiteiten of in Master opleidingen. Sommigen zien het zo dat daar dan het 'echte onderzoek' plaatsvind. Maar feitelijk is het heel nuttig om de uitkomsten van dergelijk theoretisch onderzoek, daadwerkelijk toe te passen, en zo te innoveren en waarde te creëren ('valorisatie').

Naast gestructureerd onderzoek doen, moet je het ook netjes opschrijven met geen of nauwelijks spel- of stijlfouten (max 3 per pagina). Hier kan ChatGPT je bij helpen. Als een AI qua schrijfniveau al snel een 7 of 8 scoort of zelfs hoger, dan kun je eigenlijk niet meer aankomen om dit zelf wel te doen (zie figuur 1). ChatGPT en andere generatieve AI lijken een belangrijke rol te hebben als productiviteitsbooster, maar hebben ook serieuze nadelen, dus dit vraagt een kritische houding.

We zien ChatGPT dus als 'creative technology', een AI met enorm veel kennis, waarschijnlijk meer dan enig mens ooit gehad heeft, en die altijd snel met een antwoord komt. Maar die af en toe ook 'confidently wrong' is, in de woorden van Elon Musk. Ook bekende Nederlandse informaticus Edsger Dijkstra schreef lang geleden al over 'the foolishness of natural language programming':

"some still seem to equate "the ease of programming" with the ease of making undetected mistakes." - Edsger Dijkstra https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html (1979)

Prompt Engineering

"Eén prompt is geen prompt".

Via ChatGPT kun je vrij gemakkelijk vrijwel foutloze teksten laten genereren. Althans, foutloos in die zin, dat de output geen spellingsfouten of stijlfouten bevat. Inhoudelijk verzint ChatGPT af en toe gewoon wat, als het maar goed overkomt. Het klakkeloos overnemen van teksten van ChatGPT is natuurlijk niet wat we willen.

Verder heb je ook nog fouten qua formulering of doelgroep. Het verzinnen kun je voorkomen door ChatGPT hier in je gesprek een algemene prompt te geven:

Lieg niet! Als iets niet zeker is, zet dit er dan bij, of laat feiten geheel weg als ze erg onzeker zijn of niet kloppen.

Ook schrijf je een technische tekst voor een technische doelgroep. Het gebruik van heel veel bijvoeglijke naamwoorden of bijwoorden hierin is niet gepast. Zie Technical writing; 'adjectives and adverbs' is de Engelse term voor bijvoegelijke naamwoorden respectievelijk bijwoorden. Een bijwoord is een soort bijvoeglijk naamwoord, maar dan voor een werkwoord i.p.v. een zelfstandig naamwoord, e.g. "Mooie zinnen (bijv. nw.) lees je vrolijk" (bijwoord))).

"Worse, adjectives and adverbs can make technical documentation sound dangerously like marketing material." - Google Technical Writing (2023)

Zo schrijft ChatGPT standaard snel “jubelende” teksten over de tools en technologieën. ChatGPT heeft kennelijk nogal de neiging om overdrijvingen in de tekst op te nemen. Dit is meer marketing taal dan een technische en kritische tekst zoals gewenst. Voorbeelden:

• “deze essentiële tool ...”
• “dit is voor DevOps-ontwikkelaars absoluut onmisbaar”
• “tool X fungeert als cruciale pijler”
• “tool X is een uiterst waardevol instrument”
• en “van vitaal belang”.

Zulke zinsnede zijn niet acceptabel. Laat ChatGPT dit omschrijven. En als deze dat niet kan of wil, dan moet je het zelf doen. Kennelijk heeft ChatGPT een bias waardoor deze nogal positief uit de hoek komt. Deze toon is niet passend in een blog waarmee je objectiviteit uit wil stralen.

Alleen als je na je onderzoek tot de conclusie komt dat de tool inderdaad fantastisch, geweldig of onmisbaar is, dan kun je dat eventueel zo benoemen in je conclusie, maar als je inleiding al van (op dat moment nog ongefundeerd) enthousiasme aan elkaar hangt, kom je minder geloofwaardig over.

Figuur 1: 3HOOG: ChatGPT. Benieuwd hoe het afloopt?... Zie: sam.han.nl

Onderzoeksmethoden

Over de onderzoeksmethoden is een nog een workshop, maar de HBO ICT onderzoeksmethoden ben je als het goed is eerder in je studie al bekend mee geraakt. Tijdens de workshop kun je mooi nu tijdens je werk nog opkomende vragen stellen. Schrijf deze op, anders vergeet je ze. De onderzoeksmethoden geven suggesties en kwaliteitscriteria voor goed onderzoek, maar zijn geen simpele 1-2-3 of afvinklijst naar goede onderzoeksresultaten.

Ook kun je niet aan ChatGPT toevertrouwen om echt origineel werk te maken of foutloos te zijn. Deze verzint af en toe gewoon wat, dus je moet alles controleren (zie Figuur 2). Als je zelf nog geen expert bent - wat bij onderzoek per definitie zo is - dan zul je dit met andere bronnen dan ChatGPT moeten doen.

Figuur 2: Is ChatGPT veilig voor gebruik? - Aleksandr Tiulkanov on X - Onderzoeker AI & Digitaal beleid.

Als je eenmaal goede antwoorden hebt kun je ChatGPT wel inzetten om een passende inleiding met goede leeswijzer te schrijven. En ook een conclusie. In je conclusie mag je toch "geen nieuwe informatie presenteren" (zie evt. "Do's en Dont's in je conclusie op Scribr (2013)).

Ook is ChatGPT redelijk goed in het schrijven van een (management) samenvatting, als je deze het samen te vatten. Wellicht kan ChatGPT ook een aanzet tot een goede discussie geven. Of een hypothese formuleren. Het is echter wel zaak, alles te controleren. Ook of chat geen hoofdlijnen mist. Of juist heel wollig is gaan schrijven, terwijl dit niks toevoegt, hoogstens goede input verwaterd (zie figuur 3).

Figuur 3: ChatGPT: Lossy compression... of "Too Long, Didn't Write" (bron: marketoonist.com)

Stappenplan voor schrijven onderzoeksplan

Hieronder een heel aantal stappen onderverdeeld in 3 hoofdfasen A, B en C.

A. Setup ChatGPT en repo

1. Maak — als je die nog had — een ChatGPT account aan voor je @student.han.nl account
2. Maak een repo aan op GitLab waar je je onderzoek (incl. onderzoeksplan) in gaat vastleggen/opslaan/documenteren. Zet in de repository naam je eigen naam, en zorg dat deze private is. Of gebruik een GitHub classroom link van een template repository als je docent deze aanlevert.
3. Geef je teamgenoten ook toegang tot deze repository i.v.m. tussentijdse feedback volgens de 'Feedback circle' (PACT: zie opdrachtbeschrijving).

B. Prompt engineering onderzoeksvragen voor onderzoeksplan

1. Formuleer wie je doelgroep is (zie opdrachtbeschrijving) en neem dit mee in je prompts aan ChatGPT
2. Stel, met behulp van Prompt engineering, hoofdvraag en deelvragen op over je DevOps technologie en het bijbehorende (DevOps) concept.
3. Laat ChatGPT deelvragen beantwoorden, en vind relevante andere concepten en/of andere tools en pas eventueel je vragen aan (vooronderzoek/orientatieonderzoek).
4. Vind kandidaat onderzoeksmethoden voor elk van de deelvragen (minstens 3, maar liever meer en scherpe deelvragen dan bij het minimum blijven)
5. Laat ChatGPT elk van je deelvragen kort beantwoorden (geef deze prompt met max. aantal woorden)
6. Vind per deelvraag een of meerdere relevante bronnen (anders dan ChatGPT) voor eerste verificatie

C. Vastleggen, format checks

1. Leg de doelgroep de (voorlopige) hoofdvraag en deelvragen en bijbehorende onderzoeksmethoden vast in een onderzoeksplan.md in je repository
2. Voeg hierin ook een korte (APA) bronnenlijst onderaan toe met kopje ## Bronnen (met iig als bronnen de Research methods, de AIM controlekaart, ChatGPT, en extra bron per deelvraag, dus minstens 7 bronnen)
3. Zorg hierbij ook dat dat de bron titel cursief zijn in markdown en dat er ook referentie uit de tekst is naar je bron, zoals
4. Installeer/activeer ook markdown linter (in bv VS Code), en haal lint fouten uit je onderzoeksplan.md, zoals missende witregels rondom kopjes of bullet lijsten

D. Oefenen met markdown en AIM controlekaart

1. Zet alvast het logo van de CNCF tool/technologie als markdown afbeelding in je onderzoeksplan, of een ander relevant logo en laat deze rechts alignen (<img src="plaatjes/plaatje.jpg" width="200>" align="right"; html is ook markdown)
2. Neem ook een ander plaatje op, die 'gewoon' links aligned en block, en geef deze ook een 'caption' *Figuur 1*: <Beschrijving> en verwijs met dit figuurnr ernaar in je tekst (gebruik niet 'hierboven' of 'plaatje hieronder')
3. Check dat de URL's van opgenomen bronnen ook in je bronnenlijst staan (geraadpleegd op jj-mm-jjjj via <url>), en NIET als links in je hoofdtekst
4. Zoek ook wat stemmige afbeeldingen om je tekst te ondersteunen. Sla wel meteen de bron URL op, en neem deze ook op bronnen correct volgens APA. Zoek ook met bv. de Google image search met optie voor 'Creative Common werk', zie screenshot (University of Edinburgh, z.d.).

Figuur 4: Gebruik vrije plaatjes uit Google image search of vergelijkbaar

1. en dat deze URL's ook NIET onnodig lang zijn, doordat ze bv. nog #tekst fragment of fbclid of andere onnodige tracking codes bevat (je moet evt. link tekst zelf IN je tekst zetten als quote of parafrase, en niet in bronnenlijst verstoppen)
2. Kijk tot slot of ChatGPT erg in de lijdende vorm heeft geschreven, en of je dit kunt laten herschrijven in de actieve vorm zoals de AIM controle kaart vraagt.
3. Lees de AIM controlekaart en vink af of je document voldoet aan alle verplichte items. Heeft je onderzoekplan bv. een inleiding, kerntekst en (korte) conclusie? Staan je zinnen in de actieve vorm (weet je überhaupt wat dit inhoudt :S?). Pas dit nog aan. Dit was een mooie oefening voor je onderzoeksverslag, waar je hetzelfde moet doen!

Meldt bevindingen en vragen n.a.v. deze workshop bij de docent. Zorg dat deze dringende vragen beantwoordt.

Figuur 5: De toekomst van AI? - Bron CommitStrip.com

Tot slot

Voorlopig kunnen we AI nog goed gebruiken. Maar wat de toekomst brengt is onbekend. Er zijn grote kansen, maar ook grote risico's. Simpel verbieden kan niet, want er is ook argument te maken dat het onethisch is AI niet te gebruiken, gezien de grote uitdaging waar onze maatschappij nog voorstaat. Maar we moeten wel zorgen dat AI ge-aligned blijft.

PS: Dit stuk is nog geheel zonder hulp van ChatGPT geschreven. Alsnog kan het fouten bevatten; zo ja meldt deze even.

Figuur 6: ChatGPT als 'bullshitter' - Geen tijdbespaarder, maar normverhoger?

Het plaatje van figuur 6 mag je zelf even goed bekijken en over nadenken. Voor beperken grootte van plaatje/screenshot zijn beschrijvingen onder de 4 boeken eruit geknipt, maar verder is het plaatje niet bewerkt. De 2e bron (en dus ook beschrijving erbij) kon ik niet vinden via google, en had Chat verzonnen. Dit gaf deze ook meteen toe... Hieronder nog twee relevante quotes.

"ChatGPT [...] sometimes generates nonsense but overall it provides reasonable and and quite useful answers to our questions. So it’s a smart system; amazingly smart. But it’s also “bullshit”..." (Wikipedia z.d.)

En om de wellicht wat 'popy-jopy' of grof klinkende term 'bullshit' uit deze quote nog wat toe te lichten, want dit is inmiddels ook een in de wetenschap/filosofie onderzocht em beschreven woord.

"'On Bullshit' is een essay van de Amerikaanse filosoof Harry Frankfurt dat in 1986 werd gepubliceerd. [..]. Frankfurt [...] concludeert dat de spreker die zich van bullshit bedient niet geïnteresseerd is in de waarheid, maar alleen een mooi beeld van zichzelf wil scheppen. Volgens Frankfurt is bullshit een grotere bedreiging voor de waarheid dan de leugen" (Feeny 2023)

Figuur 7: XKDC over 'AI methodology'

Bronnen

• Commitstrip.com (april 2016) Meanwhile in a parallel universe. Will humans take our jobs? Geraadpleegd september 2023 op https://www.commitstrip.com/en/2016/04/14/meanwhile-in-a-parallel-universe-3/
• Driessen, Y. (feb 2023). 3 Hoog achter: ChatGPT. Geraadpleegd september 2023 op https://sam.han.nl/achtergrond/strip/3hoog-chatgpt/
• Feeney, P. (1 feb 2023) ChatGPT, “Bullshit” and the State of Artificial Intelligence. Geraadpleegd september 2023 op https://nl.wikipedia.org/wiki/On_Bullshit
• Marketoonist (juni 2023) Impact of ChatGPT. Geraadpleegd september 2023 op https://marketoonist.com/2023/06/impact-of-chatgpt.html
• Scribbr - (15 dec 2022). Scharwächter, V. Zo schrijf je een perfecte conclusie voor je scriptie | Met voorbeeld - Geraadpleegd oktober 2023 op https://www.scribbr.nl/scriptie-structuur/conclusie-scriptie/
• Wikipedia (z.d.) On Bullshit. Geraadpleegd september 2023 op https://medium.com/@patrick_97213/chatgpt-bullshit-and-the-state-of-artificial-intelligence-1b0f9c64079e
• XKDC z.d. AI Methodology. Geraadpleegd september 2023 op https://xkcd.com/2451/
• Google, z.d. - Technical writing. Geraadpleegd 31-10-2023 https://developers.google.com/tech-writing/one/clear-sentences
• The University of Edinburgh (z.d.) How to Google search for Creative Commons licensed resources Geraadpleegd op 2-11-2023 op https://open.ed.ac.uk/how-to-guides-old/how-to-google-search-for-creative-commons-licensed-resources/
• Dijkstra, E. (1979) *On the foolishness of "natural language programming".()

Week 6 - Individueel Onderzoek - Dev

Lesoverzicht onderzoeksweek

• Les 1 - Toelichting opdracht
• Les 2 - Vragenuur onderzoeksopdracht (& presentatie)
• Les 3 - PACT feedback onderzoeksblog, teams presentatie voorbereiden
  • (lokaal beschikbaar voor peer assessment en overleg met docent)
• Les 4 - Eindpresentaties: Pitching some major DevOps tools
  • (Presentaties in groespformat, jury van docenten en begeleiders)

Deze week doe je zelfstandig je eigen onderzoek, maar er zijn uiteraard wel enkele lessen/sessie om je te helpen in een week iets moois te leveren. Lees hier verdere eisen, tips, ideen voor onderzoeksonderwerpen en meer over indeling van contacturen in de onderzoeksweek.

Figuur 1: De website voor HBO ICT Onderzoeksmethoden: icresearchmethods.nl

Zorg voor variatie in onderzoeksmethoden (triangulatie), combineer methoden (research patterns); zie figuur 1.

Mogelijke onderwerpen, tips en indeling van onderzoeksweek 6

Je doet een week zelfstandig onderzoek en verdiept je in een nieuwe DevOps technologie die in het verlengde ligt van het geleerde in lesweken. Nieuw betekent dat de techniek vrij recent is geintroduceerd, en in verlengde betekent dus onderwerp dat niet in detail tijdens de les is langsgekomen. De techniek kan bv. wel een plugin zijn van een wel behandelde tool/techniek, een nieuwe framework, taal, library. Als deliverable schrijf je een blog voor mede IT'ers (peers e.g. zeg maar je klasgenoten). Deze is van voldoende kwaliteit dat je deze online zou durven/willen publiceren. Als je wil mag je hem zelf online zetten op medium.com, LinkedIn, je eigen website o.i.d., of we zetten ze gewoon allemaal hier op de site.)

De lessen in deze week zijn als ondersteuning, en vragen aan docent, maar ook voor onderlinge feedback met andere studenten. Hierbij hanteer je waar mogelijk de AIM controlekaart.

Opdrachtbeschrijving blog + presentatie

Je vindt hier de opdrachtbeschrijving.

Onderwerp van verslag

Je moet een nieuw onderwerp vinden, die een mede student niet heeft gekozen (ook niet in een evt. vorige jaargang), maar dus wel in het verlengde ligt van een wel behandeld onderwerp. Wel moet het onderwerp een 'hands on' karakter hebben, want je moet je techniek tijdens het beroepsproduct kunnen toepassen.

Kortgezegd moet er ook wat relevante code of configuratie in je blog voorkomen. De lezer moet dit kunnen plaatsen en gebruiken bij zelf naspelen (in kader van beschrijven van je onderzoeksmethode wat je bij goed onderzoek doet). Je kunt verschillende aanpakken gebruiken, bijvoorbeeld

• vergelijken van twee tools, franmeworks, talen in een bepaald gebied
• of een bepaald concept beschrijven en dan een toepassing te vinden

Vorm en inhoud

Hieronder staan wat tips. Deze regels zijn grotendeels ook van toepassing voor grotere documenten dan een blog. Zorg voor:

1. een goede en liefst prikkelende/grappige titel (naming things)
2. begin met de eindconclusie (Pyramid Principle)
3. actieve vorm (er wordt NIET lijdend geschreven :P)
4. APA bronnen (vergeet vooral ook referenties in de tekst mét quote of parafrase)
5. Inhoudsopgave, goede tekststructuur en leeswijzers

Onderstaande paragrafen lichten dit verder toe.

1. Inhoudelijke en liefst prikkelende titel/naam van je blog

Onder het motto van de eerste van 'two hard things in computer science': naming things (Karlton, Vakil, 199x/2017) is het de bedoeling dat je je blog een interessante of prikkelende titel geeft. Dus niet 'Blog van Jan', maar een titel die iets zegt over de inhoud. Bij 'naming things' gaat veelal over variabele namen of bestandsnamen, waarbij gewoon 'recht toe rechtaan' naam het beste is. Maar in de titel mag je ook nog evt. prikkelend of humoristische titel gebruik. Of een samenvattend concept of idee.

2. Pyramid principle

Onder het motto 'start with the end in mind' van Stephen Covey en de pyramid principle van Barbara Minto geef je in de eerste 1, 2 of 3 alinea's direct een overzicht en de belangrijkste eindconclusie van het artikel. Je blog moet onderhoudend en goed geschreven zoals een normaal boek, maar NIET spannend zijn, of toewerken naar een ontknoping zoals een detective. In een technische tekst draai je deze pyramide om: de lezer leest meteen aan het begin 'who done it', en kan dan doorbladeren naar de onderliggende secties voor details waarover deze nog vragen heeft, zoals 'waar' en 'met welk wapen' zoals in Cluedo ;) (zie figuur 1). Wélke details relevant zijn, en dus de structuur van je tekst maak je zelf ook duidelijk in je tekst via leeswijzers, zie punt 5 'tekststructuur'.

Figuur 2: Vertel in een technische tekst meteen 'who done it', maak het NIET spannend.

Lees meer over de Pyramid Principle op pagina 'Onderzoek: eisen en tips'.

3. Schrijf actief, vermijd de lijdende vorm

Conform de AIM controlekaart mag er niet in de lijdende vorm geschreven worden vermijd je de lijdende vorm! Hier zijn we extra streng op om te oefenen voor het afstuderen. Hoewel sommige docenten in onderzoek (onderzoeksverslagen) de lijdende vorm wat eerder toestaan dan in een puur zakelijke of technische tekst past dit minder bij een meer persoonlijke tekst.

4. AIM-controlekaart punten

Waar mogelijk voldoe je ook aan andere eisen uit de AIM-controlekaart. Er is geen voorblad. Door punt 1 heb je wel een titel die op een voorblad niet zou misstaan. Vermeld ook een datum, of periode (alleen maand, of evt. startdatum, en datum laatst bijgewerkt o.i.d.). Als je herkansing hebt of feedback hebt gehad wellicht korte versietabel met korte beschrijving aanpassingen en/of uitbreidingen.

5. Inhoudsopgave, tekststructuur en APA

In een online blog zijn paginanummers NIET relevant. Wel neem je een Inhoudsopgave op (also known as 'ToC' ='Table of Contents', die je bv. genereert met een markdown plugin (Tran, 2023).

Je zorgt WEL voor structurering van je blog via secties en subsecties.

Je gebruikt in je tekst van je blog minstens 6 bronnen MET APA referenties. Dit zijn GEEN (directe) hyperlinks, maar:

1. referenties in de tekst tussen haakjes
2. en een Bronnen deel (ZONDER sectienummer) onderaan je blog.

Je referenties zijn volgens APA (en dus GEEN bibliografie). De gelinkte bronnen zijn GEEN voorpagina's van tool met alleen maar marketing en introductie die de lezer ook als 1e google hit zal vinden.

Bv.

"We werken met Kubernetes (Kubernetes, z.d.). Hieronder zie je het gebruikte deployment YAML bestand met een RollingUpdate..."

of

"De opdrachtgever gebruikt bij een aantal klanten de Kubernetes tool Argo (Argo, z.d.)"

Streef in plaats hiervan naar deeplinks naar een tutorial of blog over een specifiek onderwerp waaruit je een stuk tekst kunt 'parafraseren' of zelfs een letterlijke quote kunt halen. Met zo'n quote of parafrase heeft de lezer een idee heeft waar het gerefeerde artikel over gaat, en dingen hier kan checken of uitpluizen. Maar niet verplicht is de bron te bekijken om je verhaal te kunnen begrijpen.

"In Kubernetes gebruik je een deployment om te beschrijven hoe je systeem moet draaien. De deployment strategie geeft aan hoe Kubernetes bij afwijkingen tussen de daadwerkelijke situatie en de gewenste situatie weer terug kan komen in die gewenste situatie. Figuur 3 geeft de configuratie weer in het .yaml format. De gebruikte deployment strategie is de standaard RollingUpdate zodat 'updates are applied gradually, replacing a few pods at a time instead of reconfiguring the entire deployment all at once" (Bassey, 2024)". Om ook 'Failed update halts' die Bassey (2024) noemt mogelijk te maken heb ik ook health monitoring mogelijk gemaakt via instellen van een Liveness Probe' (Kubernetes, 2024).

Dergelijke stukken (e.g. gedeeplinkte blogs of artikelen) hebben ook eerder een auteur of bedrijf-/organisatieteam die je kunt opvoeren, dan een standaard algemene 'landingspagina'. En ook een datu, (evt. een 'date last updated' mist dit "pertains to the content you are citing" (Texas Medical Center Library, 2024)).

Merk op dat APA-referenties in de tekst VOOR de punt moeten (Scribbr, z.d). Dus NIET erna. Bij de zin waar het bij hoort… (quote of parafrase). Tenzij deze hele paragraaf een quote is, maar dan moet je deze ook laten inspringen. Maar dat doe je alleen bij een hele lange van meer dan 40 woorden, want anders geef je quote altijd binnen... quotes (")) (Project APA7, 2021).

Ook kun je Engelse citaten prima overnemen. Scribbr blogger Bas Swaen schrijft (2023):

"Soms wil je een citaat overnemen uit een anderstalige bron. Een citaat in het Engels kun je vaak zonder problemen overnemen in je Nederlandse scriptie, maar voor andere talen is dit lastiger, omdat lezers die taal mogelijk niet beheersen. Dan kun je ervoor kiezen om het citaat te vertalen.

Volgens de APA-stijl spreek je bij een vertaling niet langer van een citaat, maar van een parafrase. Je behandelt de bron als een normale parafrase en plaatst dus geen dubbele aanhalingstekens."

Over het mixen van Engels en Nederlands in een zin kan ik niet direct wat vinden op Scribbr. Maar analoog aan onze 'DDD' variabele namen zoals 'BushalteController' of 'VerzekeringService' is het binnen deze minor prima toegestaan.

Bronnen

• Bassey, M. (7 Aug 2024) Kubernetes Deployments: A Guide to the Rolling Update Deployment Strategy. Geraadpleegd op 10-6-2024 op https://semaphoreci.com/blog/kubernetes-rolling-update-deployment
• Cluedo Plaatje (Hoekstra, R. - 2004) Spelmagazijn - Spelbeschrijving- Cluedo. Geraadpleegd juni 2024 van http://www.spelmagazijn.nl/nl/spelmag/cluedo.html
• Kubernetes.io (30 aug 2024) Configure Liveness, Readiness and Startup Probes Geraadpleegd 10 oktober 2024 op https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
• Project APA7 (2021). APA-richtlijnen 7e editie: Parafraseren en Citeren. YouTube. Tijdens beoordelen geraadpleegd, gecheckt op https://www.youtube.com/watch?v=I-hrMg6oHGw&t=245s
• Scribbr (z.d.). Moet ik de verwijzing in de tekst voor of na de punt plaatsen?. Scribbr Tijdens beoordelen geraadpleegd, gecheckt op https://www.scribbr.nl/veel-gestelde-vragen/plaatsing-verwijzing-in-tekst/
• Swaen, B. (2023, 03 april). APA-stijl richtlijnen voor uitzonderingen | Uitleg & voorbeelden. Scribbr. Geraadpleegd op 8 oktober 2024 op https://www.scribbr.nl/apa-stijl/uitzonderingen-verwijzingen-de-tekst-volgens-de-apa-regels/#link-Citaatvertalen
• Team Professional Skills (juli 2014). AIM Controlekaart documenten. Geraadpleegd oktober 2018 op https://factlearning.files.wordpress.com/2016/02/controlekaart-documenten-ica.pdf
• Texas Medical Center Library (Feb 19, 2024) Date - APA Citation Style - LibGuides Geraadpleegd op 10-10-2024 op https://libguides.library.tmc.edu/APA/Date
• Tran, H. (22-8-2023), Auto Markdown TOC. Geraadpleegd 10-6-2024 op https://marketplace.visualstudio.com/items?itemName=huntertran.auto-markdown-toc
• Vakil, A.S. (13 mei 2017) The Hardest Problems in Computer Science. speakerdeck.com Geraadpleegd op 10-6-2024 op https://speakerdeck.com/vakila/the-hardest-problems-in-computer-science

Verdere bronnen (incorrect of zonder goede referentie ter illustratie):

• Kubernetes (z.d.) Kubernetes. Geraadpleegd op 2021-09-03 op https://kubernetes.io
• Argo (z.d.), Argo. Geraadpleegd op 2021-09-03 op https://argoproj.github.io

Individueel Blog+Presentatie als team

Introductie/TL; DR

Doe een onderzoek naar een DevOps technologie en schrijf hier (individueel) een blogpost over en geef een korte presentatie (in teamverband). Onderzoek hierbij een DevOps tool die hoort bij een van de onderwerpen van de workshops en lessen uit de course fase. Je mag er zelf een kiezen, waarover je graag nog meer zou willen weten. Kijk hierbij ook vooruit naar de eindopdracht, en technologie die je hierbij kan helpen om een hoger niveau uit het CDMM te halen.

Technologie is een vrij algemene term, maar dit is bewust. Regelmatig is dit een DevOps Tool, zoals CRIO of , maar de technologie mag ook een een framework of library zijn of zelfs programmeertool. Het kan ook een 'standaard' zijn, zoals bv. toml. Maar omdat je onderzoek ook een 'hands-on'/praktisch karakter moet hebben is het wel goed om hier ook een tool bij te zoeken.

Schrijf een blogpost samen met ChatGPT. Verifieer deze daarna met andere bronnen, en zorg dat je zelf het begrijpt. Herschrijf en vul aan met met andere (online) bronnen, en schrap vooral gedeelten die niet kloppen of wollig zijn. Voeg een stuk hands-on toe, in vorm van tutorial volgen en stukken code of config schrijven.

Je geeft ook een korte presentatie waarin je laat zien dat je het begrijpt. Dit is een 'pitch' van deze DevOps technologie. Orienteer je ook of de technologie samenwerkt met andere technologieen die teamgenoten daar gaan gebruiken/introduceren. Bedenk een hoofdvraag en deelvragen en vind hierbij onderzoeksmethoden.

Welke onderwerpen?

Kortgezegd kun je een DevOps tool uit het CNCF landschap pakken. En deze koppelen aan een concept uit CDMM, of ander concept of DevOps credo of buzzword.

• Per groep moet er minstens 1 persoon zijn die een onderwerp rondom SlackOps onderzoekt (wegens vervallen Prometheus)
• Het kan zijn dat er een onderwerp in de workshops was waarover jij niet zo veel nieuws hebt geleerd (omdat je die kennis al in huis had), maar waarvan je toch nog wat meer zou willen weten.
• Het kan ook zijn dat je een workshop hebt gehad waarvan je juist heel veel geleerd heeft, maar die je extra goed duidelijk wilt krijgen en og meer wil weten.
• Het kan ook nog zo zijn dat je in een combinatie van onderwerpen uit de workshops een mogelijkheid ziet om jezelf verder te verdiepen.

Doelgroep

Welk onderwerp je ook kiest: het is de bedoeling dat je je op dat onderwerp verder gaat verdiepen en dat je daarover een blog post (een stuk tekst) produceert die aansluit op het niveau van de minorcourse. De blog post moet te begrijpen zijn door je klasgenoten (peers) en hen ook nieuwe info moeten geven. Maar de tekst ook te begrijpen door buitenstaanders met hetzelfde kennisniveau als je klasgenoten (ICT'ers), maar die de minor niet volgen. Dus geef ook wat korte context van de minor waar je in zit. Dit kan met één zin en een linkje.

Je schrijft dus een verhaal met een kop en een staart: inleiding, kerntekst en conclusie (AIM controlekaart). In een blogpost is dit echter wel wat vrijer, dus — anders dan in een onderzoeksverslag - gebruik je niet letterlijk deze kopjes. Maar je deelt het wel in drieen. Je gebruikt ook bronnen en refereert hiernaar met een quote of parafrasering, zodat je de lezer niet dwingt de bronnen zelf te lezen (alleen als check).

Lijdende vorm

De AIM controlekaart geeft aan dat je NIET in de lijdende vorm moet schrijven. Dit is de laatste regel, en hier doen studenten vaak niks mee, of ze realiseren zich niet eens precies wat het betekent. In de versie van controlekaart op deze site is regel 11 over de lijdende vorm is herschreven in de actieve vorm, in het kader van "eating your own dogfood":

"Je schrijft het document in de actieve vorm. Het bevat nagenoeg geen lijdende zinnen."

Ook in het bedrijfsleven is regelmatig aandacht voor 'actief schrijven'. Google heeft in hun (online) course over Technical writing ook een prominente plaats gegeven (zie figuur 1).

Figuur 1: Google Technical writing - 'Active vs passive voice'

Dit voorbeeld geeft mooi aan dat lijdende vorm niet alleen te voorkomt als 'word/worden' + voltooid deelwoord maar ook als 'is/zijn' + voltooid deelwoord. Wel geldt nog dat als je merkt dat je makkelijker schrijft door wel de lijdende vorm te gebruiken, en regel 11 je dus blokkeert, dat het prima is wel lijdend te zchrijven. Zolang je de tekst maar herschrijft vóórdat je deze inlevert. Zoek een keer op 'word' in je tekst, en als het vaker dan 5 keer voorkomt weet je zeker dat je moet gaan herschrijven en de tekst een stukje korter kan.

Zolang de tekst uiteindelijk maar (overwegend) in de actieve vorm staat. Ander is het wollig en vaak onvoldoende duidelijk. De Google course 'Technical writing' is een nieuwere bron die nog eens het nut van schrijven in de actieve vorm uitlegt: "Je geeft meer context".

In een analogie tussen (natuurlijke) tekst schrijven en (programmeer)code schrijven is het ook belang om actief te schrijven om zo responsability te assignen (denk 'Single Responsability' en 'GRASP', etc.)

Een begin: "Er wordt een controle gedaan dat de ingegeven gebruikersnaam bestaat."

Vraag: Door wie? Ga jij bij al die mensen staan met een lijst en tik je ze op de schouder als ze een al bestaande gebruikersnaam ingeven.

Beter: "Het systeem controleert dat..."

Vraag: Welk deel van 'het systeem'? Is dit een front-end controle, of back-end. Front-end is door hackers makkelijk te omzeilen. Belangrijke checks, zoals bestaande gebruikersnaam moet je sowieso dubbel checken ook op de server.

Nog beter: "Bij inloggen controleert de back-end dat..." Vraag: Hoe ziet de code er dan ongeveer uit, gezien we elders kozen voor JAX-RS Restful endpoints..

Uiteindelijk in SDD: "In het REST endpoint op de back-end doet de aan dit endpoint gekoppelde methode login() in de LoginResource een controle dat..."

Nu ga je meer riochting het punt dat een junior developer het met jouw spec moet kunnen implementeren... Oftewel, zoeken naar actieve vorm en expliciet verantwoordelijkheden toewijzen en daarbij je problemen opdelen in deelproblemen helpt je straks in ICT werk ook te gaan richting een team lead, in plaats van een 'code monkey'.

Hands-on karakter

In je blog post moet je ook code en/of configuratie beschrijven, dus je blog bevat ook één of meerdere secties aan de hand waarvan de lezer zelf iets kan programmeren, configureren en/of beschreven stappen van toolgebruik kan naspelen. Kies hierbij wel voor 'configuration as code' en/of 'scripting' in plaats van hele handleiding met veel screenshots van te zetten vinkjes in GUI's, omdat dit laatste sneller verouderd.

Link ook naar je repository. Zet deze repository bij voorkeur op GitLab of GitHub (GitHub als deze publiek moet zijn/bewaard mag blijven).

Zorg wel dat je niet alleen hands-on stuk hebt, maar ook de nodige concepten uitlegt en context en introductie in je blog hebt. En natuurlijk ook een conclusie/recap.

Markdown, format en structuur

De blog is geschreven in markdown, met hierin ook gebruik van plaatjes en afwisseling van vrije tekst en gestructureerde vormen als tabellen, bullet lijsten en eventueel grafieken. Sluit aan bij format van bestaande blogs hier op de site. Gebruik ook afbeeldingen in je blog, en zorg dat deze ondersteunen en geef deze figuurnr's (caption), tenzij ze zuiver illustratief zijn. Verwijs in je tekst o.b.v. deze figuurnummers en schrijf ook toelichting bij zaken die vragen kunnen oproepen. Gebruik wel 'Creative Common' plaatjes om problemen met auteursrecht te voorkomen. Zorg ook dat je attributie doet voor de plaatjes, door 'ook bij het gebruik van afbeeldingen de bron te noemen (hier dan ook APA bron voor gebruiken).

De blogpost heeft ook eens structuur met koppen en subkoppen. Eventueel ook nog subsubkoppen, maar niet 'dieper' dan dat, want wat voor code geldt; geldt ook voor schrijven:

"If you need more than three levels [...], you're screwed anyway" - Linus Torvalds, Linux kernel coding style, z.d.

Schrijf de blogpost (net als vorige opdrachten) weer in een prive repo op gitlab. De blog staat direct in de README.md of je linkt vanuit de README.md naar je blogpost.md of <blog-onderwerp-coole-titel-cq-url-slug-voor-seo> omdat je repo ook een apart onderzoeksplan.md met je hoofd- en deelvragen en onderzoeksmethoden en toelichting.

Puntsgewijze samenvatting

• Schrijf de resultaten van je onderzoek op in de vorm van een blog-post (in het Nederlands! dus geen Engels of anderszins).
• Het is de bedoeling dat je onderzoek ofwel verbredend is (je betrekt er bijvoorbeeld onderwerpen bij die niet in de workshop zijn behandeld, of je past het onderwerp toe in een heel andere context), ofwel verdiepend is (je gaat dieper in op het onderwerp/de techniek doordat je bijvoorbeeld technischere bronnen aanboort of het onderwerp toepast in een complexere situatie). Een combinatie mag ook. In elk geval moet je duidelijk een toevoeging maken op wat de docent in de lessen behandeld heeft.
• Een korte introductie van je onderwerp hoort bij je blogpost, maar je mag ervan uitgaan dat de lezers geen “beginners” zijn op het gebied van jouw onderwerp. Ga ongeveer uit van je eigen niveau op het moment dat je met het onderzoek begon. Het eindniveau van de workshops dus, ongeveer.
• Een korte beschrijving van je onderzoekmethode (eventueel met verwijzingen naar gebruikte methoden zoals die van ictresearchmethods.nl) hoort ook bij je verslaglegging. We verwachten degelijk onderbouwd, traceerbaar en reproduceerbaar werk in je blog.
• Gebruik bronnen en verwijs hiernaar
  • dat mag door links naar websites op te nemen in je tekst (gebruik waar mogelijk en relevant ook anchors om te verwijzen naar specifieke secties)
  • maar het moet ook met [APA], dus een Bronnen lijst onderaan met al je bronnen (bij ICT meestal webpagina's) (HAN studiecentra 2021-a)
  • en bij APA hoort ook in je blogtekst voor elke bron een quote of parafrase, dus: "in eigen woorden weergeven van andermans werk [...] gevolgd door een verwijzing tussen haakjes met de achternaam van de auteur(s), het jaartal ..." (HAN studiecentra 2021-b).
• Je tekst moet opgemaakt zijn met Markdown. Dat is later eventueel eenvoudig te converteren naar HTML. Je mag eventueel bijlagen bijvoegen. Deze hoeven niet in Markdown te zijn opgemaakt. Wanneer je gebruik maakt van bijlagen, verwijs hier dan duidelijk naar vanuit de tekst. Wanneer je bijvoorbeeld kleine stukjes code wil toevoegen mag je die gewoon “embedded” opnemen. Voeg uiteraard wel bronvermelding toe wanneer de code niet van je eigen hand is!
• Je levert je werk in op iSAS en voegt eventuele bijlagen toe door ze samen met het Markdown-bestand in een zip-bestand te zetten en dat in te leveren.
• We gaan ervan uit dat je in deze week van deze course al je tijd aan deze opdracht besteedt. Dat betekent dus dat het onderzoek, schrijfwerk en voorbereiden presentatie je zo’n 40 uur zou moeten kosten. Dit is inclusief het plannen van je werk, het zoeken naar bronnen, het uitvoeren van experimenten, het uitzoeken en oplossen van technische problemen en het schrijven van je tekst. We verwachten deze tijdsinvestering terug te zien in de complexiteit en/of omvang van je werk.

Beoordelingscriteria onderzoek

Figuur 1:

Hierboven een screenshot van het beoordelingsformulier uit 2021. De beoordelingscriteria zijn onderverdeeld in de volgende drie categorieën:

• Onderwerp, diepgang, theorie/praktijk (KO)
• Helderheid en doelgroepgerichtheid
• Bronvermelding

Zie iSAS voor de precieze beoordelingsfactoren- en criteria (editie van 2023, check dat link kloot; dit kan jaarlijks licht veranderen)

Kortgezegd schrijf je een blog over je onderzoek naar een onderwerp dat in het verlengde van de minor ligt, met als doelgroep je klasgenoten, dat aansluit bij geleerde theorie en een hands-on karakter waarbij je laat zien dat je goede bronnen hebt geraadpleegden via referentie naar goede bronnen. Maximaal 1500 woorden (ca 3 A4), exclusief bronnen en code, minimaal 800 woorden (2 A4).

Hieronder meer over onderwerp, vorm en inhoud en eisen en werkwijze voor je blogpost en onderzoek.

Onderzochte technologie toepassen in (team!) beroepsproduct

Sta in een eventueel onderzoeksplan ook stil bij de eis voor toepassen van de nu onderzochte technologie in je beroepsproduct de laatste 2 weken. Denk dus vast vooruit naar PitStop en scan hier bv. nog eens doorheen wat er in zit, en bij past.

Overleg idealiter met beoogde teamgenoten voor beroepsproduct. Zij moeten immers ook hun technologie toepassen; dus er moeten een aantal technologieen in de microservces applicatie ‘passen’ die hopelijk ook enigszins aanvullend zijn of ‘orthogonaal’ (onderling onafhankelijk) zijn. Het is nuttig om even over te brainstormen.

Sluit een PACT voor peer feedback in je team

Sluit binnen je team een PACT™ af: dit is de Peer Assessment Circle Tactic™.

Bijvoorbeeld als je team 4 teamleden gaat bevatten: Teamlid 1 --> Teamlid 2 --> Teamlid 3 --> Teamlid 4 --> `Teamlid 1``

Op deze manier hou je peer assessment binnen je groep om elkaars tech vast te leren kennen, maar zorg je ook voor dat NIET jouw assessee ook jouw assessor is, wat ongewenst 'mooi weer spelen' in de hand zou werken. Zachte heelmeesters maken stinkende wonden... (e.g. alles wat uit peer assessment komt, komt beoordelaar niet meer tegen bij echte beoordeling).

Zet de gekregen feedback van je teamgenoot in je onderzoeks repo. Als je de feedback in een mail kreeg of Slack bericht kun je het copy-paste het onderaan in je onderzoeksplan.md. Of als teamgenoot feedback in een issue of je GitHub of Gitlab repo zetten, kun je een link hiernaar toe zetten. Geef in je onderzoeksplan zelf ook aan wat je van deze feedback verwerkt hebt en waarom.

Je teamgenoot kan ook het beoordelingsformullier invullen. Als je dit voor een ander doet kun je hier kritischer mee omgaan, en ook het formulier zelf goed leren kennen, ook voor je eigen presentatie.

Teampresentatie

Op basis van je bevindingen bereid je een korte 'pitch' presentatie voor. Je pitch'ed je onderzochte technologie. Of manier van inzet hiervoor. Deze stem je af met teamgenoten op mogelijke punten waar techniek elkaar aanvult, of juist clashen. Je oefent je pitch op teamgenoten en op de docent.

DOMBLR: DevOps Markdown Blog Linting Rules

In 2024 is een eerste aanzet gemaakt tot een set custom Markdown linting rules, met als doel bepaalde kwaliteitscontroles te automatiseren. Deze linting rules zijn een uitbreiding op standaard Markdown lint (van David Anson, 2024), en zijn specifiek afgestemd op de onderzoeksblogs voor de minor DevOps. Deze helpen bij het waarborgen van consistentie en naleving van de opmaakvereisten.

Status: Work in Progress

Deze linting rules bevinden zich in de onderzoeksrepository en zullen onder andere controleren op:

• Check op maximaal 1500 woorden (exclusief code blokken)
• Correcte aanwezigheid van verplichte elementen zoals studentnaam, datum, en startafbeelding.
• Aangepaste teksten in verplichte afbeeldingen (alt- en title-teksten).
• Aanbevolen minimale hoeveelheid illustraties ter ondersteuning van de tekst.
• Structuureisen zoals het gebruik van

  ---

  -elementen en overzichtelijke blokken.

Deze geautomatiseerde checks vormen een eerste stap naar een volledige review en zijn vooral bedoeld om standaardproblemen te verminderen. Ze zijn niet bedoeld als een volledige kwaliteitsgarantie, maar helpen wel om de basisvoorwaarden op orde te krijgen.

Figuur 2: ChatGPT's illustratie van linting: het verwijderen van fluff als metafoor voor het opschonen van code

Meer over de onderzoeksweek

• Mogelijk onderwerpen, peer assessment, verdere eisen en tips...

Gebruikte bronnen

• Anson, D. (2024) markdownlint Geraadpleegd november 2024 op https://www.npmjs.com/package/markdownlint
• • HAN Studiecentra (2021, 29 september) APA: Bronnenlijst - 5.1 Webpagina Geraadpleegd op 6 oktober 2021 op https://specials.han.nl/sites/studiecentra/auteursrechten/bronnen-vermelden/apa-normen/#comp00005aa289fd0000003b2b1b5c
• HAN Studiecentra (2021, 6 september) APA: In de tekst - Parafraseren. Geraadpleegd op 6 oktober 2021 op https://specials.han.nl/sites/studiecentra/auteursrechten/bronnen-vermelden/apa-normen-citeren-en-par/#comp00004b902de60000000bbf453d

Onderzoek: Toelichting en tips bij schrijven

In week 6 verdiep je je in een DevOps technologie en schrijft hier een eigen blogpost over.

Vanwege het verplicht 'hands-on' karakter kies je als onderwerp dus een redelijke concrete tool, framework en niet een heel algemeen onderwerp. Dus kies bijvoorbeeld 'Google Cloud AI Platform' in plaats van 'Artificial Intelligence'. Je blog post moet een hands-on karakter hebben. Er moet ook (voorbeeld) code of configuratie in je blog post voorkomen.

Maar je geeft elkaar ook onderling feedback. Je vormt ook vast de teams voor de eindopdracht volgende week en zorgt dat de te onderzoeken technologieen op de een of andere manier op elkaar aansluiten. Dat deze ook bruikbaar zijn tijdens realisatie van beroepsproduct in de 2 laatste weken van de course.

Hieronder verdere informatie, zoals knock-outs, suggesties voor onderwerpen/technologieen, tips.

1. Knock-outs

• Je bent niet bij de groepspresentatie of hier blijkt dat je niks hebt onderzocht of voorbereid
• Je hebt geen duidelijke en beschrijvende titel voor je blog (laat staan 'pakkend')
• Blog post NIET in markdown/tekst format, geen (extra) code in je repo (waar je naar verwijst)
• Geen code of configuratie in je blog post (deze moet 'hands-on' zijn)
• Er zit geen goede plaatjes in je blog (zelfs niet een paar)
• Te veel gebruik passieve vorm (zeg >= 5x 'wordt' in je tekst) of toekomende tijd
• Je blog is te veel een reclamepraatje: veel onuitgelegde bijvoeglijke naamwoorden of bijwoorden
• Geen goeie introductie (denk ook aan de leeswijzer hierin (=geen kopje!))
• Geen conclusie/afsluiting
• Als je een onderzoeksverslag hebt geschreven in plaats van een blog
• Geen goede structuur; niet opgesplitst in logische secties en evt. subsecties
• Minder dan 800 woorden, of (veel) meer dan 1500 woorden (exclusief config/code)
• Minder dan 5 referenties naar externe bronnen (en/of niet goed conform APA, zoals geen referenties in de tekst naar (al) je bronnen)

2. Voorbeelden van onderwerpen voor je onderzoek

Hieronder een lijst van mogelijke/geschikte onderwerpen, als er bij je zelf geen inspiratie/prangende onderzoeksvraag is ontstaan tijdens de voorgaande course weken. Kijk ook eens naar de onderwerpen op de 'not list' uit de minor chartering.

OPS

• runc
• ContainerD
• K3S/Rancher
• LXC/LXD
• Portshift, Pod scanning
• Terraform
• Build bakery

Dev

• Istio
• gRPC
• LinkerD
• Grafana
• Event sourcing
• Chaos engineering met Gremlin
• SonarQube
• Helm
• Crio
• Rancher
• K3S
• Prometheus (log/statistics)
• linkerD (service mesh)

Dev of Ops

• Kubernetes Custom Resources
• Services Meshes en Istio (of LinkerD)
• Kubernetes security en container scanning
• Secret management en certificates
• Site Reliability Engineering (SRE)
• AKS vs on premise K8S

3. Onderzoeksplan schrijven (optioneel, maar aangeraden)

Voor de blogpost is de eis dat je je eigen unieke onderwerp kiest binnen de klas. Om echt de volle week te gebruiken en niet te stranden moet je het gewenste onderwerp voor aanvang van de onderzoeksweek al gekozen hebben. En ook een reserve onderwerp. Op maandag, met hulp van een workshop schrijf je hierbij een onderzoeksplan met een concrete hoofdvraag en bijbehorende deelvragen (minimaal 3 en maximaal 7). Je hebt ook nagedacht over de te gebruiken onderzoeksmethode en sluit aan bij de ICT onderzoeksmethoden (die HAN medewerkers mede ontwikkelden).

Dit laatste doe je door voor elke deelvraag een geschikte onderzoeksmethode te vinden/kiezen en te benoemen. Maak hierbij NIET de veelgemaakte fout om onderzoeksmethode te verwarren met onderzoeksruimte ('lab' is bv. GEEN onderzoeksmethode, maar een -ruimte met hierbinnen meerdere methoden zoals 'component test' en 'unit test') (zie figuur 1). Varieer wel in onderzoeksruimte voor de triangulatie (DOT framework). De focus tijdens onderzoek ligt op Lab en Workshop onderzoek. Field onderzoek gebeurt meer tijdens ontwikkelen van beroepsproduct. De zogenaamde 'triangulatie' uit de 'DOT Framework' die achter de de ICT onderzoeksmethoden zit.

Met je onderzoeksplan zorg je dat je ook echt vragen stelt, en beantwoord en trianguleert. Deze kijken we niet per se na, maar bij twijfel over de kwaliteit kan beoordelaar dit erbij pakken. Een prima onderzoeksplan kan een twijfelachtige blogpost toch het voordeel van de twijfel geven.

Figuur 1: Overzicht van onderzoeksmethoden (deel ervan, bron: /methods-overview, 2023)

Je mag ook de joker gebruiken. Je kunt de onderzoeksmethoden een beetje vergelijken met 'patterns', het is een naam voor een aanpak van een veelvoorkomende type probleem. Zorg dat je ook echt iets met deze aanpak doet door ook de ingredienten te gebruiken. Dus in plaats van (alleen) een tabel of bullet list te geven van je onderzoeksvragen en voor elk de gebruikte onderzoeksmethode, schrijf je ook gewoon een stuk vrije tekst om dit uit te leggen

Als je de joker in zet is het het sterkst is natuurlijk als je je eigen onderzoeksmethode dan een naam geeft. Hoewel je in het 1e jaars wellicht nog wel een introductie bij de bibliotheek hebt gehad, gebruikt eigenlijk 100% van de studenten uitsluitend internet als bron. Oftewel googlen. Je kunt ook de CMD onderzoeksmethoden. Maar noem/kies ook concrete 'en relevante ingredienten' uit de gekozen onderzoeksmethode.

De deliverable van je onderzoek is GEEN onderzoeksverslag, maar een blog post. Dus met minder formeel taalgebruik. Een onderzoeksplan is ook niet verplicht, maar kan je zelf wel helpen. En het wel aanwezig zijn (van bv. een onderzoeksplan.md in je repo) is een goede safeguard mocht je onderzoek toch tegen vallen (ook bewijsmateriaal voor beoordelaar).

4. Vooronderzoek

Voordat je een onderzoek start, moet je wel wat vooronderzoek doen om de goede vraag te kunnen stellen. Om een idee te hebben of je een vraag in een middagje kunt beantwoorden (te klein, wellicht een deelvraag van maken of scope uitbreiden) of dat het wellicht maanden duurt (te groot, deel aspect pakken, onderzoek op een precies framework toe spitsen). Of dat deze precies goed is (goldilocks zonde ;).

5. Peer assessment

De voorlaatste dag van de week doe je onderling peer assessment. Doe dit zowel mondeling als schriftelijk. Schriftelijk voor de aantoonbaarheid, en ook zodat de ander het ook rustig verwerken. Mondeling kun je details verder bespreken en vragen, en dit is goed om de feedback niet té comprehensive te maken.

Je kan het zo aanpakken:

• Geef de ander toegang tot je prive repo en deze maakt een issue aan met hierin feedback.
• Een pull request met suggesties voor verbetering stijl of fixen typo’s van concrete tekst.
• En een beoordeling a.d.h.v. de beoordelingcriteria uit beoordelingsmodel op iSAS. Deze zijn in 3 hoofdcategorieën:
• Onderwerp, diepgang, theorie/praktijk (KO)
• Helderheid en doelgroepgerichtheid
• Bronvermelding

Verwerk de gegeven feedback.

6. Schrijftips

Hieronder enkele schrijftips

1. Gebruik zowel vrije tekst als meer gestructureerde elementen als tabellen en bullet lijsten
2. Maak je werk reproduceerbaar en verifieerbaar door je werkwijze te beschrijven en bronnen te geven
3. Geef je blogpost een logische structuur zodat deze leesbaar is

Hieronder verdere toelichting voor elk van deze punten. Lees ook eens deze blogpost van copyschool.nl (Driel, 2020). De tips 14 tot en met 19 van Jantien kun je negeren, want deze zijn meer voor weekbladen, maar de rest snijdt houdt; ook voor meer technische blogs.

6.1 Afwisseling tussen vrije tekst en gestructureerde elementen

Zorg dat je tekst structuur heeft. Door bijvoorbeeld het gebruik van bullet lijsten en/of tabellen. Maar zorg ook dat je blog niet ALLEEN uit bullet lijsten en tabellen bestaat (wat je veel studenten ziet doen in afstudeerverslagen). Dit doe je door ook vrije tekst toe te voegen. Geef elke bullet lijst een inleidende zin: wat voor soort items staan er in de lijst. Is het een en-en lijst? Of een of-of (e.g. beschrijft deze bv. alternatieve strategieen)? Al dit soort zaken zijn wellicht wel af te leiden door de lezer. Maar in een goed stuk hoeft de lezer weinig na te denken om het te begrijpen en heeft de schrijver juist extra veel nagedacht en/of moeite erin gestopt om de tekst duidelijk te maken. Zie verder ook sectie 'pyramid principle'.

Deze vrije tekst zelf structureer je wel via paragrafen. Paragrafen scheidt je van elkaar door een witregel. Als je enkel een harde enter plaatst kan het zijn dat de laatste zin van je paragraaf net zo lang is dat deze tot het eind van de regel loopt. Waardoor een lezer alsnog geen paragraaf overgang ziet. Bijvoorbeeld als een lezer op een mobiel device je artikel leest, terwijl je hem in desktop zelf hebt ingetikt.

6.2 Reproduceerbaarheid en gebruik bronnen (en conform APA)

Goed onderzoek is reproduceerbaar. Dat wil zeggen dat als iemand anders hetzelfde onderzoek doet dat deze tot dezelfde resultaten leidt. Alleen zulk onderzoek is betrouwbaar, en met de resultaten van zulk onderzoek kunnen anderen ook verder. En op de 'shoulders of giants' staan.

"If I had more time, I would have written you a shorter letter." - Blaise Pascal. (De kritische student onder jullie vraagt zich nu wellicht af waarom een Fransman een Engelse quote krijgt toegedicht. Een goede vraag...)

Binnen het HBO vinden we het belangrijk dat je een 'onderzoekende' mentaliteit hebt. Zeker in ICT leiden we namelijk op voor beroepen die wellicht nu nog helemaal niet bestaan. Wellicht wordt je een DevOps engineer, wat al wel een gangbare naam is, en tevens goedverdiendende rol ook nog. Maar wellicht verzint een bedrijf een meer of minder 'buzzwordy' titel voor hun vacture.

De internet variant van referenties zijn natuurlijk hyperlinks. En bij HBO ICT zijn 90+% van de bronnen internetbronnen. Voor je blog post moet je echter wel APA gebruiken. Deels om alvast te oefenen voor je afstuderen. Of omdat je begeleidend docent zelf ook echt streng is op precies APA gebruik. Regelmatig gebruiken studenten ook voetnoten bij het geven van APA referenties, maar dit is NIET het idee van APA en dus ook NIET conform APA. Dat wil zeggen: Voetnoten zijn niet verboden, maar voetnoten zijn voor voetnoten, dus een optionele toelichting op iets. Dit is iets anders dan bronvermelding, dit is bij de HAN niet optioneel, maar verplicht!

Een voor veel studenten onbekend issue is het verschil tussen een Literatuurlijst en een Bibliografie. En omdat Word als standaardtitel voor zo'n sectie 'Bibliografie' heeft, wordt dit veelal zo ingeleverd. Maar APA vereist een literatuurlijst, en dat is strikter dan een bibliografie, omdat in een literatuurlijst naar elke bron in deze lijst ook een referentie vanuit je tekst moet zijn.

Een bibliografie is een lijst van alle werken die je hebt gelezen tijdens het schrijven van een stuk. Maar hierbij hoef je niet per se te refereren naar de werken. Je zou bij wijze van spreken het kinderboek 'Pa Pinkelman en tante Pollewop' (Zonderland, D.) op kunnen nemen in je bibliografie, als dit boek je bijzonder veel ontspanning gaf tijdens een zware afstudeerperiode 😉. Maar omdat dit boek niet relevant past het NIET in een literatuurlijst.

Maar zonder gekheid, APA gaat dus uit van een 'Literatuurlijst', bij de HAN vaak 'Bronnen' genoemd!

6.3 Structureren van je blog post: section by feature (WIP)

Programmeertalen en natuurlijke talen zijn behoorlijk verschillend, maar er zijn ook overeenkomsten. Hierop gaan we hier niet verder in, maar wellicht een leuke oefening voor de lezer hiervan enkele voor zichzelf te noteren. Beiden hebben syntax én semantiek. Bij beiden moet ook een vertaalslag plaatsvinden; hetzij naar concepten in het menselijk brein, hetzij naar machine instructies die een processor kan uitvoeren bij het runnen van het programma.

Zo zijn ook code schrijven en tekst schrijven twee verschillende dingen, maar ook hier kun je overeenkomsten vinden. Een daarvan is dat structuur belangrijk is. Je programma deel je op functies. En in classes en/of modules zodra het enige schaal krijgt.

Hóe je het programma opdeelt is deel van het ontwerp, en zelfs van de (software) architectuur, want deze structuur verander je niet zomaar. Deze gaan dus horen bij de architectuur van je programma.

"Architecture is that part of design that is hard to change."

Een van de meest gestelde vragen van nieuwe programmeurs is: 'Ik heb het werkend, maar waar moet ik deze code neerzetten? In welke folder?'. Als je op dat moment geen duidelijk antwoord hebt, en maar wat gaat doen, creeer je een precedent. Dan gaat iedereen zijn eigen regels volgen. Om dit te voorkomen is het standaard antwoord vaak: de controller moet 'gewoon' bij de andere Controllers. Er is ook een mapje voor de Views en de Services.

Op deze oplossing is nogal wat op af te dingen, vooral als de applicatie over de jaren groeit en zeker als je 'Domain Driven Design' aanhangt (zoals in deze minor). Als je 'opeens' 10 of meer services in één folder hebt staan. Twee van deze services worden vanuit allerlei plekken gebruikt, vanuit de andere services en ook vanuit die ene repository, dat had wellicht netter gemoten, maar ja, het werkt wel. De andere 8 gebruik je slechts vanuit 'hun' controller, die in een heel ander mapje staat.

In een applicatie/repo/project heb je grofweg twee manieren om code te structureren:

• package by type
• package by feature

Dit idee van 'controllers bij controllers' noemt men Package by type . Alles bij zijn eigen type. Dit geeft wel een duidelijk antwoord. Waar plaats ik een service? In de services folder. En veel CLI's of IDE's geven je zelfs al een services folder en een controllers folder etc. om je extra productief te maken en zulke moeilijke vragen als 'waar moet deze klasse?' te voorkomen.

Maar zoals vaak komen de kosten van aan het begin minder nadenken later dubbel terug. De 'package by feature' optie vraagt wat meer denkwerk, want nu moet je zorgen dat de klasse of module een goede naam heeft. Namelijk die van zijn functionaliteit. Gaat deze code over 'rekeningen' (bills) of over voorraadbeheer (inventory)? En is het voorraadbeheer van de producten die je verkoopt (inventory/sales), of voorraadbeheer van spullen die je intern in bedrijf gebruikt en periodiek moet vernieuwen (/inventory/production). Of kun je folder 'inventory/sales' beter hernoemen naar stock om aan te sluiten bij woorden die ze in de business gebruiken? Nou dit neigt al naar de Ubiquitous language, zo'n beetje het belangrijkste pattern uit Domein Driven Design.

De package by feature' aanpak betekent in ieder geval dat de folderstructuur is niet meer standaard hetzelfde voor alle projecten, maar de folderstructuur geeft aan wat de applicatie doet. Als de stock folder 2x zoveel bestanden en/of subdirectories bevat als de inventory folder, geeft dit duidelijk aan dat hier meer logica in zit. En dat dit deel wellicht voor de core business in het bedrijf ook belangrijker is. En/of dat het complexer is om goed te automatiseren.

Het zal duidelijk zijn dat deze laatste te prefereren valt. Hoewel het vooral bedoeld is voor grotere projecten mag je hier zeker mee experimenteren ook in de wat kleinere projectjes op school. In het echte bedrijfsleven moet je zeker niet zomaar gaan switchen naar andere folder structuur, zonder eerst akkoord van management en/of afstemmen met mede developers. Er is ook nog de middenweg van package-by-type-by feature. Of package-by-feature-by-type. Dit mag je zelf bedenken wat dit is (/stock/controllers/ en stock/services). Maar als een folder maar een of een paar bestanden bevat, dan is een eigen subfolder NIET nodig.

Om de structuurmethode 'package by feature' te vertalen naar programmacode geldt dus ook dat je je blogpost opdeelt in subsecties. En dat je niet 1 sectie hebt waarin je voor alle deelvragen introduceert. Dan 1 sectie waarin je voor elke deelvraag de onderzoeksmethode berschrijft. En dan 1 sectie waarin je de bevindingen voor elke deelvraag opschrijft. En dan 1 sectie met de conclusie voor alle deelvragen. Je behandelt per al deze onderdelen binnen een sectie per deelvraag.

Wel heb je een introducerende sectie nodig die deze structuur beschrijft, en dus wel alle deelvragen en bijbehorende onderzoeksmethoden bv. kort opsomt. Gebruik verder per sectie ook niet de deelvraag zelf als sectietitel, maar gebruik een kortere variant hiervan. Kopjes is niet de bedoeling dat dit de volledige vraag is, of een volledige zin. Maar meer in een krantenkop stijl. Onder het kopje kun je de deelvraag wel geheel herhalen of parafraseren. NB: Een vraag eindigt altijd op een vraagteken. Dus doe dit ook. Bedenk dat in markdown default een kopje ook niet mag eindigen met een leesteken volgens de mdlint regel. Dit is omdat "Headings are not meant to be full sentences".

Verder lezen:

• Robert C. Martin, yes Uncle Bob himself, over package-by-feature, wat hij 'Screaming Architecture noemt': https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
• De Angular styleguide oorspronkelijk van Microsoft medewerker en PluralSight docent John Papa, met hierin de LIFT principes, inclusief argumentatie 'Waarom?': Locate code simply, Identify code at a glance, Flat folder structure en Try to be DRY: https://angular.io/guide/styleguide#lift

6.4 Pyramid principle

Als je je schrijven echt naar een hoger niveau wilt tillen verdiep je dan eens in de 'Pyramid Principle' van Barbara Minto. Je kunt haar originele boek lezen of wat samenvattende blogposts, maar dat is wellicht wat zwaar. De essentie van haar verhaal is dat je vaak je 'schrijfsel' moet 'omdraaien' t.o.v. hoe je het origineel opschreef. Zie illustratieve plaatje/comic van sketchplanations in figuur 1 (Sketchplanations, z.d.)

Figuur 1: The pyramid principle in 1 plaatje (Bron: sketchplanations.com)

Dat wil dus zeggen dat je je document BEGINT met de eindconclusie die je uiteindelijk bereikt hebt. Of het eindresultaat.

Bijvoorbeeld: Ik heb een kleine webapplicatie gemaakt met een 3-tier architectuur, met front-end en database in een aparte container, en de back-end in het midden opgedeeld in 2 microservices elk draaiend in hun eigen container.

Mensen hebben namelijk standaard de neiging om verhalen chronologisch op te schrijven. Namelijk, eerst deed ik dit, en toen deed ik dat, zodat uiteindelijk... Of een argumentatie: 'omdat A het geval is, en ook B, en natuurlijk niet C1 en C2 — die je samen zou kunnen vatten als C — kom ik tot de conclusie dat D'. Dit is een vereenvoudigd voorbeeld - vandaar de variabelen - maar in werkelijkheid zou deze structuur dus jouw hele blogpost van 2 of meer A4's kunnen zijn. In plaats van de ene zin die het voorbeeld nu is. Of zelfs een heel afstudeerverslag. In de 'Minto' methode zou je dit omdraaien naar 'Ik vind dat D. Dit komt omdat A, B en C, die ik in sectie 2.3, 2.4 en 2.5 verder uitwerk.

Je moet dit niet alleen op de schaal van je hele document doen. Maar ook elk subhoofdstuk intern weer zo opdelen. Want je kent dit wellicht al in de vorm van een 'managementsamenvatting' die je vooraan een verslag zet. Of gewoon een samenvatting, want het management is lang niet altijd je doelgroep. Maar juist op het middelste niveau maakt dit je verslag leesbaarder en toegankelijker. Heel veel studenten stouen hun verslag vol met tabellen met Requirements, of bullet lijsten met user stories. Geef naast de leeswijzer in hoofstuk 1 'Inleiding' die de rest van het document beschrijft, ook elk hoofdstuk zijn eigen leeswijzer. In tegenstelling tot de leeswijzer, die aan het eind van de inleiding staat, staan deze interne leeswijzers juist direct aan het begin van hun hoofdstuk. Gebruik verder ook NIET het kopje 'Leeswijzer' voor deze sectie. En zelfs geen subkopje '3.1 Inleiding'. Gebruik voor sectie kopjes zoveel mogelijk inhoudelijke termen uit je applicatie, die gaan over WAT je beschrijft. En niet HOE je het beschrijft. Dit laatste kun je toelichten in tekst zelf, of wijst zichzelf.

Dus NIET sectie of hoofdstuk '4. MoSCow' (HOE je de prioritering aangeeft), maar '4. Prioriteiten' met daarin 1e paragraaf: "Tabel 4.1 hieronder geeft de prioriteitsindeling van de user stories uit H3 volgens de MoSCoW methode (Mulder, P., 2017), zoals besproken met de product owner."

Bronnen

• Bonestroo, W.J., Meesters, M., Niels, R., Schagen, J.D., Henneke, L., Turnhout, K. van (2018). ICT Research Methods. HBO-i Amsterdam. ISBN/EAN: 9990002067426. Geraadpleegd 2 september 2021 op http://www.ictresearchmethods.nl/
• ictresearchmethods.nl. Oktober 2023. Methods overview Geraadpleegd 24 oktober op https://ictresearchmethods.nl/methods-overview/
• HAN Studiecentra, 28 mei 2018, APA: In de tekst, geraadpleegd 2 september 2021 op https://specials.han.nl/sites/studiecentra/auteursrechten/bronnen-vermelden/apa-normen-citeren-en-par/
• Sketchplanations (z.d.) The Pyramid Principle - Sketchplanations. Geraadpleegd 10 juni 2024 op: https://sketchplanations.com/the-pyramid-principle
• Driel J. van (5-4-2020) 44 schrijftips. copyschool.nl. Geraadpleegd november 2024 op https://www.copyschool.nl/blog/44-schrijftips

Controlekaart documenten AIM^*

Een document dient aan al onderstaande criteria te voldoen.

Algemeen

1. Het document is op tijd en op de juiste plek en wijze ingeleverd.
2. Het document oogt netjes (geen verspringend lettertype, geen inktvegen, geen rommelige vormgeving en geen onleesbare stukken tekst).
3. Het document is voorzien van een titel, studentnaam of -namen (alfabetisch geordend), studentnummers, klas, groepsnummer, docentnaam of -namen, datum, course/semestergegevens en versienummer.
4. Het document is voorzien van een inhoudsopgave en paginanummers.

Opbouw

5. Het stuk is opgebouwd uit hoofdstukken, paragrafen en alinea’s. Het document bevat in ieder geval een inleiding, kerntekst en conclusie.
6. Bijlagen, plaatjes en tabellen zijn een zinvolle aanvulling op de hoofdtekst.
7. Er is sprake van APA-bronvermelding en er is een APA-literatuurlijst aanwezig.

Stijl, spelling en grammatica

8. Het document is doelgericht geschreven en in de schrijfstijl is rekening gehouden met de doelgroep.
9. Vervoegingen van werkwoorden zijn correct gespeld. Er staan maximaal drie foutief gespelde werkwoorden op een willekeurige pagina.
10. Woorden zijn correct gespeld. Er staan maximaal drie foutief gespelde woorden op een willekeurige pagina.
11. Het document is in de actieve vorm geschreven. Je schrijft het document in de actieve vorm. Het bevat nagenoeg geen lijdende zinnen.

^*Noot: Bovenstaande tekst is overgenomen van de 'factlearning' Wordpress site van ICA AIM Professional skills (2016). Dat is niet meest recente, maar op dit moment nog wel dé beste plek om via Google deze controlekaart te vinden :P.

Overzicht en toelichting aanpassingen

In deze 'markdown' versie zijn t.o.v. het origineel:

• de controlepunten ook voorzien van markdown checkboxen om af te vinken voor het inleveren/uploaden: [ ] -> [x]
• Het punt over vermijden van lijdende vorm ook in de actieve vorm geschreven i.v.m. 'eat your own dogfood'
• irrelevante punten voor markdown/digitaal documenten zoals 'paginanummers' en 'geen inktvegen' doorgestreept

Merk op dat de meeste punten in het digitale tijdperk gewoon nog gelden (een automatische/interactieve inhoudsopgave/TOC kun in markdown kun je makkelijk genereren met tools bv. in Visual Studio Code)

Nu je ChatGPT kunt gebruiken om je te helpen/teksten te herschrijven moet je makkelijk foutloos kunnen schrijven i.p.v. 3 fouten per pagina. Meer moeite heeft ChatGPT met in actieve vorm schrijven, of herschrijven hiernaar. Maar modernere bronnen zoals Google's Technical writing course (Google, 2022) onderstrepen dit punt alleen nog maar, o.a.:

• Passive voice obfuscates your ideas, turning sentences on their head. Passive voice reports action indirectly.
• Some passive voice sentences omit an actor altogether, which forces the reader to guess the actor's identity.
• Active voice is generally shorter than passive voice.

Bart van der Wal - September 2023

Bronnen

• AIM Professional Skills. juni 2016. Controlekaart documenten ICA. Geraadpleegd op 22-9-2023 op https://factlearning.files.wordpress.com/2016/02/controlekaart-documenten-ica.pdf
• Google (sept 2022) Google Technical Writing - Prefer active voice to passive voice Geraadpleegd 2 okt 2023 op https://developers.google.com/tech-writing/one/active-voice#prefer_active_voice_to_passive_voice

DevOps presentaties vrijdag 13 okt 2023

Opdracht

Bereidt een korte pitch presentatie van ca. 3 minuten voor, waarin je de onderzochte DevOps technologie pitched, en mogelijkheden geeft voor toepassing in PitStop of in de opdracht in blok 2.

"Prepare a short presentation (no more than 1–3 minutes) about your product, business proposition or solution direction. Practice the pitch on a wide range of experts to collect feedback and improve it." (HBOi, 2018)

Gebruik ook je blogpost als basismateriaal, bv. de plaatjes uit de blogpost. Desgewenste kun je ook een presentatie maken, met Google Slides of Powerpoint, maar voorkom death by Powerpoint en probeer te 'spreken met impact' (Bossche, 2018)). Koppel in je presentatie je tool ook aan DevOps concepten, zoals:

• CDMM: hoort het bij een van de 5 niveaus/beoordelingscategorieen?
• Bij welk weekthema het hoort GitOps t/m SlackOps
• En/of andere concepten die je tegenkwam in de minor zoals 12factor principes, etc.

Hoe vul je de 2 a 3 minuten?

Bijvoorbeeld zo:

• 1 minuut Intro Geef kort een intro, en de context. Dus koppel het aan de minor zoals hierboven aangegeven. Of maak het nog concreter en beschrijf het probleem dat 'jouw' tool oplost, of nieuwe kans die het biedt.
• 1 minuut Hands-on Geef dan ook kort een hands-on stukje, met code en/of configuratie zodat je publiek voelt dat ze er mee aan de slag kunnen. Hiervoor kunnen ze natuurlijk ook je blog post later lezen.
• 1 minuut Lijm, kwinkslagen (Wikipedia, 2007) Het is een teampresentatie, dus maak ook als team een lopende presentatie. Laat zien dat je weet wat collega studenten hebben voorbereid en bedenk samen een logische volgorde en onderlinge 'hand-offs' en een gedeeld format van de presentatie.

Breng over wat je hebt geleerd, en laat zien dat je je verdiept hebt. Je mag ook best wat humor erin gooien, om de aandacht er bij te houden. Maar hou het ook wel kort.

Figuur 2: Spreek met impact! Dan heb je geen 3D plaatjes nodig ;)

Tijdschema

• 09:00 Lokaal open/introductie
• 09:10 Team Monaco: Sentry, Nuke Build, Zabbix (M), ArgoCD
• 09:30 Einde, vragen/feedback
• 09:35 Team TBD: Dapr, LitmusChaos, Ansible, Terraform, Grafana (M) en Tekton
• 09:55 Einde, vragen/feedback
• 10:00 Team Agile Alliance: Alibaba File Storage, OpenTelemetry, Highlight, FluxCD, Kong
• 10:20 Einde, vragen/feedback
• 10:20-10:40 Pauze
• 10:40 Team Knoppert: Prometheus, Thanos (M), Keycloack, ChaosKube, HPA
• 11:00 Einde, vragen/feedback
• 11:05 Team Luna: SonarQube, Keda, Cloud Custodian, OpenPolicy Agent, Jaeger
• 11:25 Einde, vragen/feedback
• 11:30 Team Horizon: Helm, FluentD, Apollo, gRPC en ChaosMesh
• 11:50 Einde, vragen/feedback
• 12:05 Feedback/eindbeoordelingen
• 12:15 Einde les

Jury: AIM docenten en InfoSupport medewerkers (begeleiders in blok 2)

De jury kiest:

• Beste individuele presentatie
• Beste team presentatie
• Draagt 3 onderwerpen/pitches aan voor 'Coolste tech'. De klas kiest hieruit de winnaar...

Bronnen

• Bossche, A. van (24-9-2018) Arnout Van den Bossche over Powerpoint. youtube.com. Geraadpleegd oktober 2024 op https://www.youtube.com/watch?v=QRn9mIX9-BI
• HBO-i (2018). ICT Research Methods — Methods Pack for Research in ICT. ICT Research Methods. Geraadpleegd okotber 2024 op https://ictresearchmethods.nl/showroom/pitch/
• PA van de K, Baardman, G. Wikipedia. (29-1-2007) Oneliner of Kwinkslag. Wiktionary.Geraadpleegd okober 2024 op https://nl.wikipedia.org/w/index.php?title=Oneliner&oldid=63972079

DevOps Beroepsproduct & beoordelingsmodel

Week 7

• Les 1 - Ma ocht: User Storymap maken + Casus uitwerken (teams backlog vullen en Sprint 1 inrichten)
• Les 2 - Di ocht: Sprint planning 1 (naar productie + ontwikkelen/onderzoek)
• Les 3 - Vr ochtend: 'Tech' reviews & retrospective sprint 1(e week) (naar staging)

Week 8

• Les 1 - Ma ocht: Sprint planning week 2
• Les 2 - Di ocht: Sprint retrospective
• Les 3 - Vr ocht: Eindpresentaties/teambeoordeling

Week 9

• Les 1: Ma ochtend: Indivuele verantwoording/beoordeling
• Les 2: Gaat niet door (donderdag herkansing theorie)
• Les 3: Vr ochtend: InfoSupport Workshop MCPS (Azure DevOps e.d.)

Afsluiter van de course fase is een opdracht om in teamverband een DevOps BeroepsProduct (BP) te realiseren, te deployen en in de lucht te houden en monitoren.

Het is goed om je al een keer op deze eindopdracht en beoordelingscriteria te orienteren aan het begin van de course, zodat je hier gericht naar toe kunt werken. Tijdens de course fase refereert de docent waarschijnlijk ook regelmatig aan de eindopdracht, ivm het CDDM beoordelingsmodel. En in de laatste weekopdracht(en) neem je hierop ook al een voorschotje.

In dit gedeelte voor week 7 en 8 vind je de volgende zaken:

• opdrachtomschrijving van het beroepsproduct
• het beoordelingsmodel van het BP dat je als team maakt (een rubric, uit de DevOps beroepspraktijk).
• uitleg van beoordeling van verantwoording van je individuele bijdrage en het benodigde/in te vullen template hierbij (markdown!).
• een FAQ (work in progress)

Figuur: Ontdek het DevOps 'Secret Ingredient' tijdens de course eindopdracht!

NB Tijdens de course eindopdracht leer je — eindelijk — de secret ingredient van DevOps kennen! (zie figuur; spoiler warning: filmpje NIET aanklikken!)

De DevOps minor is voltijd. Jullie worden geacht om 40 uur per week aan beroepsproduct te ontwikkelen. Dus op maandag bespreken we bovenstaand overzicht en eventuele uitwijkingen hierop. Communcatie verloopt ook via het aangemaakt Slack kanaal en/of Teams (Slack in 2024)/.

Informatie project

Vraag student

"Ik ben een beetje verward door het rooster van ISAS i.c.m het rooster op minordevops.nl. Wat zijn nu precies de lestijden voor het DevOps project volgende week? Ik wil ook netjes verlof boeken met m’n werk."

Reminder: KiesOpmaat geeft/gaf ook aan:

Rooster Er wordt vanuit gegaan dat studenten van maandag t/m vrijdag beschikbaar zijn, dus bijbaantjes of andere vakken van maandag t/m vrijdag (9.00-17.45 uur) volgen is geen optie.”

Er is in de laatste twee weken geen centrale stof meer, en ook geen theorietoetsen. We gaan de geleerde theorie toepassen, en waar nodig nog aanvullen of gaten dichten. Je werkt zelfstandig met je team werken aan de eind opdracht. Dit zijn twee sprints van een week. Hiermee oefenen we ook de vorm vam het eindproject in blok 2. Op de lesmomenten is de docent in het geroosterde lokaal, tenzij anders afgestemd. Begin van de week zijn sprint planning en eind van de week reviews. In week 2 kan begin van de week nog een retrospective met je docent zijn, of je doet dit als team zelfstandig (continuous improvement).

In week 9 is (naast theorie toets herkansing) mogelijk ook nog een bedrijfsbezoek en/of een workshop bij InfoSupport workshop. Details volgen in de lessen.

Voorbeeld tijdschema Scrum Sessie

Hieronder een voorbeeld van Sprint planning, maar dit gaat vergelijkbaar voor andere Scrum ceremonies. Dit schema gaat uit van 6 groepen. Als er minder groepen zijn, bijvoorbeeld 4, dan zijn de sessies iets langer, bv. 40 og 45 minuten. In dit voorbeeld zijn de groepsnamen nog ‘abstract’ gelaten. De daadwerkelijke teamnamen en planning moet je afstemmen met de docent (vraag dit na als deze er zelf niet mee komt!). Hierbij variëert de volgorde tussen sessies, zodat dezelfde teams niet elke keer als 1e of laatste zijn.

• 09:10-9:40 Sprint planning Team 1
• 09:45-10;10 Sprint planning Team 2
• 10:15-10:40 Sprint planning Team 3
• 10:40-10:50 Pauze docent
• 10:50-11:15 Sprint planning Team 4
• 11:20-11:45 Sprint planning Team 5
• 11:50-12:15 Sprint planning Team 6

Workshop User Story mapping

Deze workshop leer je eindopdracht kennen, maar leert ook de User Story Mapping (USM) techniek kennen. Je past deze toe voor de opdracht komende twee weken. Deze techniek gebruik je ook in het eindproject om (meer) structuur aan te brengen

Figuur 1: De oorspronkelijke analogie van van Jeff Patton de grondlegger van USM (Patton, 2008)

Voorbereiding

1. Lees het verhaal over User Story Mapping en kijk de video van 6 minuten van Atalassian op de website van de Open Practice Library ().
2. Kies een van onderstaande mogelijke 'Functionele uitbreidingen van PitStop' op, of verzin of genereer er zelf
3. Verzin voor deze casus zes (6) user stories in de standaard vorm Als <gebruikersrol> wil ik <functionaliteit> zodat ik <businesswaarde>. Hierbij:

• a. Minstens drie verschillende gebruikers(rollen) of persona's.
• b. Zoek op wat een persona is in Agile (bijvoorbeeld op Wikipedia of interaction-design.org).
• c. Zorg dat je user stories uniek zijn, anders dan die van je klasgenoten.
• d. Post je 6 user stories in Slack (eindopdracht-kanaal).
• e. Na het posten van unieke user stories kun je een casus claimen voor je groep. Overleg met je team; bij discussie beslist de docent.

NB: Het is geen gegeven dat je zelf ingediende/bedachte user stories ook mag implementeren, dit gaat in overleg met team, en hier houdt de docent veto recht.

Lesinhoud

• Maak een aantekeningen/tekening (concept map)
• The 8 Fallacies
• Intro User Story Map
• Lesopdracht: Maak met je team een user Story map van je eigen casus/user stories

Een 'Concept map' van 'User Story Map'

Opdracht studenten: Maak n.a.v. lesinhoud vandaag een concept map van User Story Mapping

Relevante termen voor deze concept map zijn o.a.:

• Value slices, prioritering
• User story map, backbone
• User stories, acceptatiecriteria en backlog/code management tool

Einde les maakt de docent een foto hiervan.

User Story Map

Figuur 2: User Story map, leeg template van miro.com

Doel van de les is een goed beeld te hebben wat een User Story Map is en waar dit voor dient, en hoe je er een kunt maken voor een concrete business case (of functionele uitbreiding). Als Figuur 2 een plaatje van een USM stond hoef je zelf geen beeld meer te maken. Dit is een leeg template van op Miro, een mooie tool.

De richtlijnen op Open Practice Library geven aan minstens 3 sprints te maken. Ook de term 'MVP' in het template is belangrijk. Dit is een soort abstract 'sprintdoel'. Maar in true 'DDD practice' moet je hier in je eigen template een concrete invulling voor maken in de 'Ubiquitous language' die je deelt/gaat delen met business experts. In plaats van hen uit te leggen wat een 'MVP' is. Want dat moeten zij uiteindelijk zelf beoordelen: wat is 'viable' in hun business? Wat levert waarde op? Wel kun je eens nadenken over varianten op MVP als 'Minimally Marketable Product' (MMP) en 'Minimal Loveable Product' (MLP).

Lesvraag: Is er een vaste volgorde in het maken van MVP, MMP en MLP? Minimally Viable Product, Marketable Product en Lovable Product!?

Intro over 'Fallacies' in algemeen

Ter overpeinzing/bespreking:

“The trouble with the world is not that we know so little. It’s that we know so much, that just ain’t so.” - Mark Twain (or is it.. ;)

• Toetsvraag fallacies of distributed computing bespreken/bekijken
  • Dit was een tricky vraag. Waarom is het nuttig te denken in termen van 'fallacies'?
• Terzijde: Toetsvraag over Autonomy over authority bekijken
  • Wat betekent hierin het (Engelse) woord over?
  • Is authority hier op meta niveau, over development team, of basisniveau, de microservice zelf? Snap je het onderscheid?

The 8 Fallacies of User stories

Hier zijn 3 fallacies. Verzin met de klas er nog 5. Bekijk de lijst die de docent toont.

Invest principes

Een beetje het tegenovergestelde van deze zelf bedacht 8 fallacies is het INVEST principe van Bill Wake (Wikipedia, 2024). Deze geldt voor PBI's, maar User stories is daar een vorm van. Deze moet je hanteren in het project bij het maken van sprint planningen, of bij het nadenken van value slices in je User Story Map. Hieronder de korte definitie van Wikipedia, maar het artikel van Philip Rogers op logrocket.com is wat toegankelijker met plaatjes en meer toelichting (2018).

"..the characteristics of a good quality Product Backlog Item (commonly written in user story format, but not required to be) or PBI for short. Such PBIs may be used in a Scrum backlog, Kanban board or XP project."

Letter	Meaning	Description
I	Independent	The PBI should be self-contained.
N	Negotiable	PBIs are not explicit contracts and should leave space for discussion.
V	Valuable	A PBI must deliver value to the stakeholders.
E	Estimable	You must always be able to estimate the size of a PBI.
S	Small	PBIs should not be so big as to become impossible to plan/task/prioritize within a level of accuracy.
T	Testable	The PBI or its related description must provide the necessary information to make test development possible.

Agile: GEEN WaterScrumFall

Agile wordt wel eens foutief aangegrepen als excuus om 'gewoon aan de slag te gaan' zonder verder te plannen of na te denken. Het is belangrijk om aan de slag te gaan en niet verstrikt te raken in 'analysis paralysis'. Maar met een beetje nadenken vantevoren kun je vaak veel verspilde tijd later voorkomen. En nadenken over een Road map voor je product samen met opdrachtgever en andere stakeholders. Dit kan in de vorm van een User Story Map. Hiermee zet je ook wat 'sprint goals' uit voor de 1e paar Sprints. Dit Requirements Engineering' stukje kun je ook iteratief aanpakken, in plaats van waterfall. Zodat je niet in de val trapt van 'WaterScrumFall' zoals Jez Humble het noemt:

"After witnessing a handful of Agile transformations, oftentimes the system of Waterfall isn’t entirely replaced by Agile, merely paved over. The DevOps group might have embraced it, but the rest of the business is still operating in a “Non-Agile”, project-that-starts-and-ends, style." - Steven Prutzman (2023)

Figuur 2: Simon Brown predikt 'Just enough upfront design' (YouTube/Brown, 2022)

Naast Humble's WaterScrumfall concept benadrukt ook C4 creator ook Simon Brown's praatje 'The lost Art of Software Architecture' hoe enige INVESTering zich kan uitbetalen in tijdsbesparing later. Dit is zeker een kijktip! Je software architectuur uitdenken met het C4 model is hier een vorm van. Maar aan de domein-/functionele kant is User Story Mapping hier een goede vorm voor.'

Quiz

Test je kennis met deze korte multiple choice quiz.

Leerdoelen

Check met onderstaande leerdoelen of je de stof beheerst en User Story mapping en gerelateerde kennis in de vingers hebt.

• Je kunt uitleggen wat User Story Mapping (USM) is en waarom het belangrijk is voor projectplanning.
• Je kunt beschrijven hoe USM helpt bij het prioriteren van user stories in DevOps projecten.
• Je kunt het INVEST-principe uitleggen en toepassen op het maken van sterke user stories.
• Je begrijpt wat fallacies zijn (algemene misvattingen) en kunt misvattingen in user stories herkennen als ze worden gegeven.
• Je kunt het verschil uitleggen tussen user stories en andere Product Backlog Items (PBI’s), zoals taken, bugs en epics.
• Je kunt een backbone en value slices beschrijven in een User Story Map.

Casussen Uitbreiding Pitstop

Kies een van onderstaande casussen of maak er zelf een.

Casus 1. Klant 'in the loop'

Notificatie systeem naar gebruikers dat reparatie gestart is, of reparatie klaar, of evt. input tussentijds nodig is Image(goedkeuren reparatie a.d.h.v. kosten) (huidige notificatie systeem in het systeem is alleen naar klanten dat een onderhoudsbeurt nodig is).

Doel is vooral de response tijd van klanten te verkleinen, wachttijden verkleinen voor efficiënter gebruik van garage werkplaatsen.

Casus 2. Leenauto’s: geluk bij een ongeluk

Klanten kunnen tijdens reparatie ook een leenauto krijgen. Hiertoe moeten zij digitaal kunnen aangeven dát ze dit willen, zo ja met wat soort auto, en iets kunnen vinden over voorwaarden, inleverdatum etc.

Hierbij werkt PitStop samen met een Leasemaatschappij, en richten zich op klanten die wel eens een ‘leuke/andere’ auto willen uitproberen als ‘geluk bij een ongeluk’ als ze een (al dan niet geplande) reparatie hebben.

Casus 3. Doe het zelf avonden

Module voor inplannen en aanmelden voor informatieavonden, waarbij klanten in de garage kunnen mee sleutelen onder leiding van reparateur. Dit doet PitStop vooral voor klantenbinding. De workshops richt zich vooral op wat klanten met wat oudere auto’s, wat een aantal reparateurs leuk vindt, en ook onder klanten animo voor is. En ook vanwege moeilijk te krijgen personeel, en dat de garage in de avonduren nu toch ongebruikt is.

Casus 4. Andere eigen functionaliteit

Figuur 3: Wie is creatiever; mens of machine? Bron: Dean Long (2023)

Studentengroepen kunnen ook zelf een functionaliteit plannen, mits passend bij Pitstop, en niet te groot en niet te klein. Wees zelf creatief. Of gebruik desgewenst ChatGPT als 'assistive technology' of 'creative technology' om een suggestie. Kader deze wel met de nodige informatie. Geef hem de beschrijving huidige functonaliteit zoals Edwin van Wijk die opgeeft in documentatie in zijn github repo. Geef hem daarna de drie voorbeeld casussen/functionaleiten als eh.... voorbeeld. Maar itereer (prompt) ook wel door op wat ChatGPT je geeft krijgt. Onderstaand is een - vrij uitgebreide - start prompt die deze zaken bevat:

"Genereer een context- en opdrachtbeschrijving voor een nieuwe PitStop uitbreiding Zie de opdrachtbeschrijving en 3 voorbeelden op de minordevops.nl site. Concreet:

1. Raadpleeg de bestaande functionaliteit van Microservice applicatie PitStop over 'Garage Maintenance' op https://github.com/EdwinVW/pitstop/wiki/Application%20functionality. Vertaal dit naar het Nederlands voor de introductie (onderdeel C hieronder)
2. Raadpleeg dan de sectie "Voorbeelden van functionele uitbreidingen" op </week-7-8-beroepsproduct/opdracht-beschrijving.html#voorbeelden-van-functionele-uitbreidingen>
3. De 4e optie beschrijft daar al het 'zelf verzinnen' eventueel met hulp van ChatGPT. Voor de gewenste functionele uitbreiding van PitStop genereer je 7 zaken:

• a. een coole project naam a la "Leenauto's" of "Klant in the loop", maar dan voor een nieuwe/andere functionele uitbreiding
• b. En ook een creatieve ondertitel, hierbij zoals "Geluk bij een Ongeluk"
• c. Een Nederlandse vertaling en parafrasering van de standaard functionaliteit van PitsStop via de eerder gegeven URL op github.com/EdwinVW als context beschrijving en introductie in een h2 kopje 'Context'.
• d. Een korte opdrachtbeschrijving waarin je minstens 2 gebruikersgroepen noemt en ook wat details qua 'working objects' als 'lijstjes', 'notificaties', 'overzicht', 'start ticker' of 'go/no beslissing' en functionaliteit en domeintermen uit PitStop zoals 'reparatie', 'doorlooptijd' en nieuwe termen uit de uitbreiding (dit zijn voorbeelden, gebruik deze NIET letterlijk, tenzij ze voor de door jou bedacht uitbreiding ook toevalllig relevant zijn)
• e. Genereer ook direct een afbeelding bij de opdracht, in lijn met de andere 3 (tekening rondom het thema, met liefst hierop een of meer personen in beweging (een beetje 'in actie').
• f. Geef tot slot een disclaimer dat dit een fictieve casus is, en dat genoemde API's en partijen niet per se echt zijn.
• g. Geef de bronnen, de 2 URL's op github.com en minordevops.nl van hierboven

Geef dan aan dat je graag door itereert op wat je hebt gemaakt. "Want één prompt is geen prompt..."

Maak van al bovenstaande een duidelijke zakelijke tekst, dus GEEN marketing tekst. Schrijf actief. Wees spaarzaam met bivoegelijke naamwoorden. Bewaar marketing voor het plaatje ;). Schrijf de hele tekst in b2 niveau Nederlands en in active vorm (dus NIET lijdend e.g. met 'word/worden' of 'is/zijn' + voltooid deelwoord). Laat ook de a, b, c t/m g indeling weg uit je gegenereerde input. Dit is hierboven enkel voor het structureren van de prompt zelf. Graag 1 kopjes 1 met de Titel en dan dubbele punt en erachter de subtitel. Dan eronder direct het gegenereerde plaatje (afbeelding), liefst rechts uitgelijnd."

ChatPUG: PitStop Uitbreiding Generator

Er is per oktober 2024 ook een kant en klare 'custom GPT', een zogenaamde 'GPTs' beschikbaar. Deze bevat een uitgebreide variant van bovenstaande prompt. Hier de link naar chatgpt.com:

ChatPUG

Dit is een service aan jou, maar geeft geen garantie op dat de output goed is (e.g. 'garantie tot de deur', oftewel de plek waar jij begint met gebruiken is al GEEN ENKELE garantie meer). Dat is ter eigen beoordeling. Je kunt dit ook gebruiken 'zolang de voorraad strekt' (want Open AI kan deze feature ook betaald maken e.d.)).

Figuur 4: ChatPUG: PitStop Uitbreiding Generator

NB Een Generative AI is dus NIET betrouwbaar. En je zou het een 'slappe afspiegeling' van een echte opdrachtgever kunnen noemen. Maar het is wel een opdrachtgever met - waarschijnlijk - meer kennis dan welke 'echte' opdrachtgever ter wereld dan ook. En ook is een Genearative AI gebruiken als 'opdrachtgever' beter dan als developer zelf je eigen opdrachtgever zijn. Omdat je dan opdracht en/of requirements snel bij stelt op basis van wat makkelijk te implementeren is. Of zelf leuk lijkt.. Een bekend gezegde is "You are NOT your user". Dit gaat over UX/UI, maar is ook iets breder toepasselijk.

"User-Centred Design is surprisingly difficult. One of the biggest issues, certainly for those with no HCI or usability experience, is a lack of appreciation of how users think and work.Their assumption is that users will approach and solve problems in the same way as the designers and developers of an interactive solution." - ixDF, 2016

Maar nogmaals wel is AI en zeker LLM's (Large Language Models) structureel unexplainable en onbetrouwbaar. Daarom hieronder een belangrijke disclaimer en waarschuwing bij gebruik.

Disclaimer/waarschuwing

In essentie is het gebruik van ChatPUG niet wezenlijk anders dan bovenstaande 'handmatige' prompt gebruiken. Je hoeft nu alleen maar 'Go' in te typen o.i.d. Maar omdat de Prompt nu netjes verpakt is in een (GPTs) doosje, vergeet je wellicht dat ChatGPT fouten maakt. En dat de maker eran mogelijk ook fouten of onvolkomenheden in de prompt achter de GPTs heeft achtergelaten. Dus we raden aan om verder werken hierop en de GPTs zelf bekijken en aanpassen. En vooral zelf alle output te controleren, door te prompten en handmatig verder te werken met wat je van ChatGPT krijgt. Want als engineer kun je de gebruikte tool niet de schuld geven; je bent zelf verantwoordelijk voor je werk.

Sowieso moet je NOOIT persoonlijke gegevens of IP (Intellectual property) gevoelige gegevens in ChatGPT of andere online tools/AI's invoeren!

Ook moet je GEEN gevoelige gegevens in ChatGPT stoppen. Sowieso geen persoonsgegevens als namen of locatiegegevens. Maar onder gevoelig gegevens hoort bijvoorbeeld ook de opdracht(beschrijving) die je van de echte opdrachtgever in blok 2 van de minor DevOps krijgt.

Voor die opdracht teken je mogelijk ook een NDA (Non Disclosure Agreement). Maar ben je zonder dat ook in algemene zin een 'professionele houding' verplicht en voorzichtigheid met gevoelige gegevens. Dus vraag altijd eerst toestemming voor gebruik van AI van een opdrachtgever. Een leg deze daarbij goed uit wat je wilt doen, wat de meerwaarde kan zijn, maar ook welke alternatieven. En wat de risico's zijn. Het zelf in controle blijven, en Generative AI de (minder gevoelige) details laten verbeteren is ook vaak een betere aanpak:

"You start to rely on AI to generate content that you realistically should be ashamed to be letting a robot generate for you" (Panagis, 2024).

Hoogstens kun je als tegenmaatregel je prompt eerst zwaar anonimiseren. Of een custom AI model gebruiken in plaats van een van de tech giants. Want bij tech giants en ook in het algemeen moet je altijd bedenken dat:

"If you're not paying for the product, you ARE the product." - Andrew Lewis (Shaikh 2018)

Bronnen

• Brown, S. (13 okt 2022) The lost art of software design by Simon Brown. YouTube. Geraadpleegd 14-102-2024 op https://www.youtube.com/watch?v=36OTe7LNd6M
• Interaction Design Foundation - IxDF. (2016, February 28). Empathic Design: Is Empathy the UX Holy Grail?. IxDF. Geraadpleegd 14-10-2024 op https://www.interaction-design.org/literature/article/empathic-design-is-empathy-the-ux-holy-grail
• Prutzman, S. (Nov 10, 2023) Is your business stuck in a Water-Scrum-FALL model? medium.com.Geraadpleegd 13-20-2024 op https://medium.com/@sprutzman/is-your-business-stuck-in-the-water-scrum-fall-model-28e3c99eca6c
• Rogers, P. (Sep 10, 2024) Writing meaningful user stories with the INVEST principle Logrocket.com. Geraadpleegd 11-20-2024 op https://blog.logrocket.com/product-management/writing-meaningful-user-stories-invest-principle/
• Takane M., De Beasi, R. (April 20, 2017) User Story Mapping & Value Slicing - Create lightweight release plans by slicing value out of collections of features Open Practice Library. Geraadpleegd op 11-10-2024 via https://openpracticelibrary.com/practice/user-story-mapping
• Panagis, A. (Aug 8, 2024) Is AI A Good Starting Point? Generative AI – The Easy Way Out scalemath.com. Geraadpleegd op 11-10-2024 via https://scalemath.com/blog/generative-ai/
• Patton, J. (8 okt 2008) The New User Story Backlog is a Map jpattonassociates.com. Geraadpleegd 11-10-2024 op https://jpattonassociates.com/the-new-backlog/
• Shaikh, F. (Nov 23, 2018) If you're not paying for the product, you are the product! LinkedIn. Geraadpleegd op 11-10-2024 via https://www.linkedin.com/pulse/youre-paying-product-you-faiz-shaikh/
• Wikipedia auteurs (17 sept 2024) INVEST (mnemonic) Wikipedia Geraadpleegd op 11-10-2024 via https://en.wikipedia.org/w/index.php?title=INVEST_(mnemonic)&oldid=1246204419

DevOps Beroepsproduct & beoordelingsmodel

Week 7

• Les 1 - Ma ocht: User Storymap maken + Casus uitwerken (teams backlog vullen en Sprint 1 inrichten)
• Les 2 - Di ocht: Sprint planning 1 (naar productie + ontwikkelen/onderzoek)
• Les 3 - Vr ochtend: 'Tech' reviews & retrospective sprint 1(e week) (naar staging)

Week 8

• Les 1 - Ma ocht: Sprint planning week 2
• Les 2 - Di ocht: Sprint retrospective
• Les 3 - Vr ocht: Eindpresentaties/teambeoordeling

Week 9

• Les 1: Ma ochtend: Indivuele verantwoording/beoordeling
• Les 2: Gaat niet door (donderdag herkansing theorie)
• Les 3: Vr ochtend: InfoSupport Workshop MCPS (Azure DevOps e.d.)

Afsluiter van de course fase is een opdracht om in teamverband een DevOps BeroepsProduct (BP) te realiseren, te deployen en in de lucht te houden en monitoren.

Het is goed om je al een keer op deze eindopdracht en beoordelingscriteria te orienteren aan het begin van de course, zodat je hier gericht naar toe kunt werken. Tijdens de course fase refereert de docent waarschijnlijk ook regelmatig aan de eindopdracht, ivm het CDDM beoordelingsmodel. En in de laatste weekopdracht(en) neem je hierop ook al een voorschotje.

In dit gedeelte voor week 7 en 8 vind je de volgende zaken:

• opdrachtomschrijving van het beroepsproduct
• het beoordelingsmodel van het BP dat je als team maakt (een rubric, uit de DevOps beroepspraktijk).
• uitleg van beoordeling van verantwoording van je individuele bijdrage en het benodigde/in te vullen template hierbij (markdown!).
• een FAQ (work in progress)

Figuur: Ontdek het DevOps 'Secret Ingredient' tijdens de course eindopdracht!

NB Tijdens de course eindopdracht leer je — eindelijk — de secret ingredient van DevOps kennen! (zie figuur; spoiler warning: filmpje NIET aanklikken!)

De DevOps minor is voltijd. Jullie worden geacht om 40 uur per week aan beroepsproduct te ontwikkelen. Dus op maandag bespreken we bovenstaand overzicht en eventuele uitwijkingen hierop. Communcatie verloopt ook via het aangemaakt Slack kanaal en/of Teams (Slack in 2024)/.

Informatie project

Vraag student

"Ik ben een beetje verward door het rooster van ISAS i.c.m het rooster op minordevops.nl. Wat zijn nu precies de lestijden voor het DevOps project volgende week? Ik wil ook netjes verlof boeken met m’n werk."

Reminder: KiesOpmaat geeft/gaf ook aan:

Rooster Er wordt vanuit gegaan dat studenten van maandag t/m vrijdag beschikbaar zijn, dus bijbaantjes of andere vakken van maandag t/m vrijdag (9.00-17.45 uur) volgen is geen optie.”

Er is in de laatste twee weken geen centrale stof meer, en ook geen theorietoetsen. We gaan de geleerde theorie toepassen, en waar nodig nog aanvullen of gaten dichten. Je werkt zelfstandig met je team werken aan de eind opdracht. Dit zijn twee sprints van een week. Hiermee oefenen we ook de vorm vam het eindproject in blok 2. Op de lesmomenten is de docent in het geroosterde lokaal, tenzij anders afgestemd. Begin van de week zijn sprint planning en eind van de week reviews. In week 2 kan begin van de week nog een retrospective met je docent zijn, of je doet dit als team zelfstandig (continuous improvement).

In week 9 is (naast theorie toets herkansing) mogelijk ook nog een bedrijfsbezoek en/of een workshop bij InfoSupport workshop. Details volgen in de lessen.

Voorbeeld tijdschema Scrum Sessie

Hieronder een voorbeeld van Sprint planning, maar dit gaat vergelijkbaar voor andere Scrum ceremonies. Dit schema gaat uit van 6 groepen. Als er minder groepen zijn, bijvoorbeeld 4, dan zijn de sessies iets langer, bv. 40 og 45 minuten. In dit voorbeeld zijn de groepsnamen nog ‘abstract’ gelaten. De daadwerkelijke teamnamen en planning moet je afstemmen met de docent (vraag dit na als deze er zelf niet mee komt!). Hierbij variëert de volgorde tussen sessies, zodat dezelfde teams niet elke keer als 1e of laatste zijn.

• 09:10-9:40 Sprint planning Team 1
• 09:45-10;10 Sprint planning Team 2
• 10:15-10:40 Sprint planning Team 3
• 10:40-10:50 Pauze docent
• 10:50-11:15 Sprint planning Team 4
• 11:20-11:45 Sprint planning Team 5
• 11:50-12:15 Sprint planning Team 6

Opdrachtbeschrijving beroepsproduct DevOps

Afsluiter van de course fase is een opdracht om een DevOps beroepsproduct te maken als team met — uiteraard — gelijkwaardige bijdrage van elk teamlid.

A. Het team:

1. deployt een applicatie (systeem) die bestaat uit meerdere containers (microservices) naar minstens één live omgeving
2. past de onderzochte DevOps technologieën uit de onderzoeksweek toe in de applicatie en/of deployment
3. voert hierop een product increment door met toepassing van de in thema weken opgedane kennis en vaardigheden

B. Elk groepslid laat zien dat hij/zij:

1. effectief samenwerkt in een team en onderling goed communiceert
2. een eigen eigen rol en specialisatie heeft gevonden
3. een bijdrage levert en een Agile aanpak hanteert.

Dit betekent een gedeelde verantwoordelijkheid en verantwoordelijkheidsgevoel. Dit beroepsproduct is zo een voorbereiding op de grote opdracht van tijdens de project fase van de minor. Daarom werk je aan een product met een moderne microservices architectuur (complexe architectuur, zie bv. Figuur 1).

Figuur 1: Voorbeeld van een microservice architectuur — waar komt jouw uitbreiding?

De bovenvermelde punten — A1, A2 en A3 en B1, B2 en B3 — zijn knock-outs. De drie punten onder B. beargumenteer je in de individuele verantwoording. De drie punten onder A zijn hieronder verder toegelicht en uitgesplitst. Met name het product increment bevat de nodige verplichte onderdelen.

Al met al moet je best veel dingen voor elkaar krijgen in twee weken. Verdeel het werk over alle teamleden en zoek naar 'twee vliegen in een klap slaan'. Kijk wat je met het toepassen van je technologieen al hebt afgedekt. Hou tot slot de gemaakte functionaliteit en architecturele aanpassing klein zoals in toelichting hieronder ook vermeldt.

Enkele opmerkingen van student na afloop van dit BP project staan onderaan. Wellicht goed om door te nemen voor een meer 'studenten perspectief'. En ook om niet aan dezelfde steen/stenen te stoten...

De knockouts zorgen voor een bepaalde minimale hoeveelheid werk die je als team moet verzetten, oftewel kwantiteit. Wellicht kun je dit i.p.v. kwanteit overigens nog beter varieteit noemen. Want in plaats van je tijd alleen steken in bv. veel functionaliteit, kun je na 1e functionaliteit beter focussen ook security analyse te doen en pipeline in te richten. Deze variateit/kwantiteit is nodig om dus een 6 te halen. Op HBO niveau geldt echter NIET 'het werkt, dus het is goed genoeg'. Eerst maak je een werkende situatie, maar daarna review en refactor je verder tot het ook onderhoudbaar, uitbreidbaar etc is. Kortom, zorg voor kwaliteit.

Voor het bepalen van de kwaliteit van het product en gebruikte proces(en ds voor een cijfer hoger dan een 6) gebruik je de CDMM beoordelingscriteria zoals elders beschreven. Naast het afvinken leg je ook uit waarom je aan de punten voldoet. E.g. toon aan dat je bewust bewkaam bent als team. De verantwoording individuele bijdrage vind je ook elders, hier de links:

• beoordeling BP (team)
• beoordeling eigen bijdrage (individueel)

A1. Applivatie live zetten (en houden)

Dit betekent dat je

• a. de applicatie werkend krijgt op een productie omgeving (dag 1 sprint 1).
• b. maar ook een (externe) staging omgeving (cq. test, QA, etc.). (dag 2 sprint 1)

Omdat je maar één K8s cluster hebt kun je hiervoor een Kubernetes namespace gebruiken (Lewis 2015). Bonus is als je de staging omgeving tijdelijk maakt, door deze test omgeving weer snel te kunnen stoppen en afbreken. Zodat er bv. minder load balancer kosten zijn.

A2. Toepassen technologieën

• a. Je past alle technologieen toe van alle teamleden in het product.
• b. Documenteert het gebruik in README, ADR's en/of verwijzing/quote uit eigen blogs
• c. En/of automatiseert in shell scripts zodat ook iemand die technologie niet kent met het product kan werken

Als technologieen alternatieven zijn, doe je PoC's en past evt. beide toe, of je kiest o.b.v. bronnen en documenteert keuze met Architecture Decision Records. Evt. clashes, problemen met technologie had je waar mogelijk voorzien tijdens onderzoeksweek, maar documenteer je anders kort met verwijzing naar evt. openstaande issue van gebruikte technologie en/of vind work-around.

Architectuur documentatie

Je software architectuur documenteer je in dit project typisch via C4 diagrammen en ADR's. Maar vergeet bij de C4 diagrammen de begeleidende toelichting niet. En bij de ADR's ook een inleiding.

Kijk voor opties voor ADR's nog eens terug in de les over Continuous Documentation

Tijdens realisatie vind geen puur 'lab' onderzoek meer plaats. Je doet veld- en werkplaatsonderzoek en verdiept je waar nodig verder in de DevOps wereld. Je toont hierbij 'vormbehoud' van niveau van de course opdrachten. Dit wil zeggen dat je de minimale eisen aan opdrachten en kennis uit de theorieweken en -toetsen hier weer laat zien. Er zijn geen uitgebreide verslagen meer nodig. Eventuele uit te zoeken zaken, zoals vragen kun je formuleren en prioriteren als gitlab issue. Uitkomsten documenteer je als ADR's, zoals in de course gedaan.

A3. Product Increment

In het product increment (figuur 2) besteed je als team — naast realisatie van nieuwe functionaliteit — ook aandacht aan het opstellen van non-functionele eisen en het hieraan voldoen via de aangeleerde DevOps aanpak. In het product increment realiseer je de volgende zes eisen:

• a. Makkelijke uitrol van je product increment, via 'niet standaard' Deployment
  • bijvoorbeeld Canary, Blue Green Deployment of gebruik van een externe tool als Helm of Ansible
• b. Aanpassing van architectuur van de applicatie, inclusief documentatie!
• c. Monitoring van hardware gebruik
  • om problemen te voorkomen en efficiency en kostenbesparing mogelijk te maken en evt. custom metric en rapportages
• d. Security aspecten, bv scan op container en/of dependency niveau
  • update van dependencies en uitrollen ervan zonder regressiefouten of voor gebruikers merkbare glitches of functionele veranderingen
• e. Automatische schaling, bv. bij meer of minder (gesimuleerde) gebruikers
• f. Fouttolerantie, design for failure en/of High Availability
  • uitvallende hardware of services erop heeft geen merkbare gevolgen (evt. Chaos engineering toepassen)

Figuur 2: Output van een Sprint is een Product increment (Bron: kiwop.com, 2020)

Toelichting/tips bij de opdracht

Het is zaak de functionele uitbreiding relatief simpel te houden. Het kan ook een prototype functionaliteit zijn, die nog verder uitgewerkt moet, mits de roadmap wel duidelijk is en evt. bugs op een 'known issues' lijst staan en workaround hebben. De uitbreiding moet dus wel enigszins realistisch zijn, en ook deels zichtbaar via UI of webservices. Ook heb je uiteraard tests geschreven voor het geautomatiseerd testen van je product increment.

De toepassing van de onderzochte technologie moet efficient zijn en pragmatisch. Ofwel: de technologie moet je helpen bij bovenstaande doelen en niet loshangen en alleen tijd gekost hebben. Denk aan het gebruik van een geautomatiseerd monitoring dashboard, toepassen van een service mesh met built in security features, of gebruik een ops tool/technieken als IaC.

Bewaar al te grote ambitie qua functionaliteit voor het project in blok 2. De kern van de opdracht is het tonen van een DevOps aanpak. Dus het is niet onoverkomelijk ook als in je functionaliteit mogelijk nog wat UI gebreken zitten, of integratiebugs. Hiermee kun je bv. ook demo'en dat dat je een rollback kunt doen...

Denk bij een architecturwijziging aan:

• één of meer nieuwe microservices toevoegen. Deze communiceren onderling of met bestaande microservices.
• Het opsplitsen van bestaande microservice in twee onderdelen met eigen verantwoordelijkheid.
• Het aanpassen van .NET microservice naar (API compatible) Java, NodeJS of microservice met een andere programmeertaal (Polyglot 'X').
• Onder Polyglot X hoort overigens naast een andere programmeertaal ook het gebruik van een andere stack, bv. Java TomEE vs Java Spring, of een aanpassing in een andere laag, bv. persistentie dus switchen van MSSQL naar MySql, PostgreSQL, een NoSQL oplossing zoals ElasticSearch of caching technologie rondom database en/of applicatie zoals Redis of RabbitMQ of Service Bus persistent of een in memory database.
• Het doorvoeren van meer Event Driven architectuur zoals aanpassen naar CQRS patroon.
• Het uitbreiden of uitsplitsen van front-end laag naar aparte microservice, een self hosted CDN aanpak of cookieless subdomain of zelfs micro frontend achtige aanpak.
• Of nog iets anders... :)

Er is bij deze opdracht GEEN externe opdrachtgever en tevens gebruik je hierbij een bestaande applicatie, zodat je zelf weinig functionaliteit/features hoeft te verzinnen. Start met een applicatie die al in containers kan draaien, zodat je deze niet van scratch hoeft op te bouwen.

In dit opzicht lijkt het op een zogenaamd brown field project, in de zin dat je NIET vanaf scratch begint, maar je moet verdiepen in een bestaande software architectuur en een deel van de details van de code en configuratie. Het gekozen project is echter wel een green field qua gebruikte technologieën en aanpak. Dus het bevat unit tests en heeft in principe een microservices architectuur. Aangeraden project is InfoSupport's Pitstop. Een alternatief is Microsoft's 'e-shop on containers' project.

Je uitbreiding moet wel uniek zijn binnen je klas. De technologieen die je hierin toepast zijn ook uniek, maar dat is bij onderzoeksopdracht als het goed is al geregeld.

Voorbeelden van functionele uitbreidingen

Kijk bij de les/workshop User Story mapping voor enkele casussen (casi?) voor een functionele uitbreiding van PitStop (met elk ook weer subonderdelen). Met een plaatje erbij van Dall-e voor een sfeer impressie. Geef wel je eigen draai aan een functionaliteit. Of verzin zelf een functionaliteit (en je eigen plaatje met Dall-e :)).

Studentenfeedback na afloop van de BP opdracht

Hier wat feedback/reflectie van studenten na afloop van het project, om een beeld te krijgen vanuit hun perspectief.

"De opdracht was aardig abstract en vaag in het begin. Na het stellen van vragen aan de docent was er meer duidelijkheid en tijdens de werkdagen kwamen we er zelf ook meer achter wat we moesten doen. Er was weinig tijd om alles goed te doen en hierdoor hebben we concessies moeten maken op bepaalde vlakken. Verder is werken aan een (redelijke) grote applicatie die jezelf niet hebt geschreven lastig en tijdrovend maar wel leerzaam voor later in het bedrijfsleven." - Student X

"Ik ben zeer tevreden met de voortgang van dit project. In het begin was het nog een beetje puzzelen wat precies de verwachtingen & eisen waren. Zodra dit bekend was bij ons waren wij al snel uit over wat we willen doen met dit project. Namelijk het toevoegen van mechanics. Al snel had ieder zijn specialiteit gevonden, in mijn geval was dat de front-end. ..." - Student Y

"In het begin was de opdracht heel onduidelijk. Ik begreep toen ook niet wat er nou precies moest gebeuren. Wat later kwam ik erachter dat wij gewoon heel vrij waren, zolang wij maar bepaalde doelen haalden. Op zich was dit wel een keer een fijne manier van werken, maar vind het persoonlijk prettiger werken wanneer er meer duidelijkheid is. Ook was de Pitstop applicatie aardig groot voor deze twee weken. Wij zijn in het begin heel veel tijd verloren aan het uitzoeken hoe Pitstop in elkaar zit." - Student Z

Bronnen

• Lewis, I. (28 Augustus 2015) Using Kubernetes Namespaces to Manage Environments, geraadpleegd 21-10-2021 op https://kubernetes.io/blog/2015/08/using-kubernetes-namespaces-to-manage/
• Long, D. Hongxin (31 juli 2023) Creating Quality Online Content in the Era of AI Geraadpleegd 5-10-2023 op https://www.deanlong.io/blog/creating-helpful-reliable-people-first-ai-content
• Kiwop (12 April 2020). Agile methodologies in web development kiwop.com. Geraadpleegd 19-12-2024 op https://www.kiwop.com/en/blog/agile-methodologies-in-web-development

Beoordelingsmodel (groepsproduct + -proces)

Als beoordelingsmodel voor de weekopdrachten en het beroepsproduct (BP) dat je maakt — gebruiken we het Continuous Delivery Maturity Model (CDMM) zoals gedefinieerd in een blogpost op de website InfoQ. Deze onderscheid vijf categorieen (rijen) met elk 5 niveaus (kolommen) met een aantal 'checkpunten'.

Hieronder een korte opsomming van de 5 categorieën uit het CDMM, met per categorie een beschrijving van belangrijke aspecten. Maar voor de verplichte self assessment moet je ook zelf de details achterhalen van de 'checkpoints', zoals onderaan de pagina verder beschreven, toegelicht onder 'DevOps concepten' op deze website, maar ook in het originele 'InfoQ' artikel (Böstrom et al., 2013).

• 🧑‍🤝‍🧑 Culture & Organization: Multidisciplinair samenwerken, conform Agile manifesto, verminderen silo's en gedeelde verantwoordelijkheid conform 'DevOps is not a role', etc. (Agile).
• ⛪ Design & Architecture: Just in time design, continuous documentation, microservice architectuur, High Availability, autonomy over authority, etc. (C4, IaC, clustering)
• 🏗️ Build & Deploy: Gescripte pipelines, continuous integration, continuous deployment, koppeling aan versiebeheer, 'automate all the things' etc. (GitOps)
• 🧪 Test & Verification: Leesbare en liefst uitvoerbare specificaties, geautomatiseerd testen, testpiramide, opstellen en meten bedrijfsmetrics, etc. (TDD, BDD, test pyramid)
• 📈 Information & Reporting Inzicht in issues/backlog, metrics vanuit productie, beeld hard- en softwaregebruik, log aggregatie, visualisatie, 'strengthen feedback loops', etc. (SlackOps)

Bovenstaand de categorieën nog even in het Engels en als toelichting een indicatie van hogere maturity per punt met wat kernpunten. Het Maturity model geeft meer stapsgewijze opbouw in niveaus met bij elk niveau checkpunten om af te vinken. Deze vind je hieronder opgesplitst over twee tabellen zodat het goed op deze pagina past:

• de beginniveaus (🐣 2, 🐥 4 en 🦆 6-)
• respectievelijk hogere niveaus (🤨 6+, 8 😍, 🤯 10)

Om niet direct te verdwalen in het detail kun je eerst overzicht te krijgen via de toelichtingin in subsecties hier eronder. Sectie A geeft een toelichting van het gebruik CDMM als beoordelingsmodel voor cijferindicatie. Sectie B licht de vijf beoordelingscriteria toe die dit model bevat. Sectie C beschrijft de samenhang met (en mapping naar) de thema's, opdrachten en lessen van de course fase. Sectie D licht de indeling van de teampresentatie momenten toe. Tot slot in sectie E iets over de impliciete aanname dat je geautomatiseerd testen en aan TDD doet. Tot slot de gebruikte Bronnen.

Voor het eind beroepsproduct van de coursefase krijg je ook een individueel cijfer. Deze is veelal gelijk aan het teamcijfer, maar zoals elders is toegelicht hoe elk teamlid hiervoor de verplichte 'verantwoording van de individuele bijdrage' geeft, via een persoonlijk markdown bestand (waarvoor een template format is), en een mondelinge toelichting hierbij tijdens de Review.

CDMM Basis tot gemiddeld

CDMM Gemiddeld tot Expert

A. Toelichting gebruik CDMM als beoordelingsmodel

Dit model is opgesteld voor ICT organisaties, om de fase van adoptie van DevOps patterns en het toepassen van Continuous Delivery aan te geven. In deze course gebruiken we dit ook voor bepalen van niveau van jullie als DevOps team. Je DevOps team zien we daarbij dus zien als een kleine DevOps organisatie.

Het model kent vijf beoordelingscategorieën met elk vijf beschreven niveaus: base, beginner, intermediate (=gemiddeld), advanced en expert. Voor de becijfering koppelen we grofweg een cijfer aan elk niveau:

• 😴 base niveau cijfer **2**
• 🥱 beginner niveau, een **4**
• 😐 gemiddeld niveau een **6**
• 🙂 gevanceerd niveau een **8**
• 😎 expert niveau een **10**

Het voldoende niveau (dus een 6) is dus intermediate oftewel gemiddeld. Hier ben je voldoende volwassen. Bij lager zit je op onvoldoende, maar dat betekent in dit geval niet dat je aanpak niet adequaat is, vandaar de gebruikte emoticons van het nog slapen en ontwaken: 😴 2 en 🥱 4. Wellicht waren deze iconen ook passend geweest: 🐣 2, 🐥 4 en 🦆 6 (😉).

Deze 'Beginner' punten moet je dus wel inrichten, dit zijn traptreden die je moet nemen naar hoger niveau. Op tenminste een aantal punten moet je ook naar gemiddeld of hoger zitten voor een voldoende. Je hebt immers een DevOps minor gevolgd, dus een bedrijf verwacht dan dat je meer DevOps kennis hebt dan de gemiddelde instappende ICT'er. Het staat de beoordelaar vrij om een tussenliggend cijfer te geven op de deelaspecten, dus bijvoorbeeld een 5, 7 of 9 is ook mogelijk (een 1 betekent dat je niks hebt gedaan of ingeleverd).

Bij de beoordeling levert de docenten/beoordelaars wel maatwerk, dus rekening houdend met omstandigheden. Bij beoordeling is het niet allen een kwestie van simpelweg afvinken, maar belangrijkste is dat je ook zelf kunt beoordelen waar je staat, de gebruikte termen goed kunt interpreteren, koppelen aan je eigen en je teams werk. Kortom dat je aantoont dat je een 'bewust bekwame' DevOps professional bent.

Verdere opmerkingen:

• De Engelse termen uit het CDMM-artikel, zoals 'base', worden afgewisseld met Nederlandse equivalenten ('basis') voor verduidelijking.
• Termen in monocase font (dus met backticks ` in markdown) verwijzen naar specifieke concepten of labels zoals beschreven in het CDMM-model.
• De termen 'beoordelingscriteria' en 'categorieën' gebruiken we in de tekst als synoniemen en verwijzen naar dezelfde onderdelen.

B. De 5 beoordelingscriteria

Onderstaand de vijf beoordelingscriteria waar je in je team laten op 'intermediate' niveau moet scoren. Als indicatie een korte beschrijving en wat voorbeelden. Maar voor beoordeling moet je de hele rubric bekijken en bekijk voor uitleg van alle 'etc.' in onderstaande het originele InfoQ artikel als verdere achtergrond. Merk op dat achter elk criterium uit CDDM tussen haakjes ook een ruw equivalent van de criteria uit de OWE.

1. 🧑‍🤝‍🧑 Cultuur & Organisatie - CO: DevOps is een cultuur (en geen rol). Van basis versiebeheer en ad hoc proces tot projectgebaseerde teams met volledig gedefinieerd DevOps proces. Het team heeft gezamenlijke verantwoordelijkheid en backlog en hanteert een Agile aanpak en ceremonies (bv. Scrum), etc. (DevOps-1 - Continuous Delivery)
2. ⛪ Design & Architectuur - OA: Ontwerp van je software architectuur. Van monoliet naar microservices mapping op infrastructuur (evt. IaC), focus op NFR's voor bv. autoscaling, twelve-factor app principles, etc. (DevOps-3 - Containerization/Orchestration)
3. 🏗️ Build & Deploy - BD: Van wat handmatige stappenplan naar volautomatische build met kwaliteitschecks en een Canary of bluegreen deploy vanuit zelf ingerichte pipeline, dev/prod parity etc. (DevOps-2 GitOps)
4. 🧪 Test & Verificatie - TV: Van wat (goede) unit tests¹ naar volledige testpiramide, load tests en tests van bedrijfswaarde. De mate van TDD, acceptatietests, BDD, security, refactorings, review-proces en -inspanningen etc. (DevOps-4 - DevSecOps)
5. 📈 Informatie & Rapportering - IR: Van standaard hardware monitoring naar realtime applicatiespecifieke metrics en cross applicatie en cluster informatie, A/B tests. Hoe goed monitor je de applicatie, static code analyse, loglevels/-aggregatie, productspecifieke rapportages, etc? (DevOps-4 - SlackOps)

Hieronder de beoordelingsrubric overgenomen van het Continuous Delivery Maturity Model (CDMM) van infoq.com. De rubric is feitelijk overgenomen uit een plaatje bij dit artikel wat een samenvatting van het artikel vormt, in de vorm van afvinkbare 'checkbox punten'. Drze zijn verdeeld over vijf categorieen die elk weer vijf niveaus van 'volwassenheid' hebben.

Wijzigingen t.o.v. originele CDMM

De wijzigingen in bovenstaande tabel ten opzicht van het originele CDMM van InfoQ zijn erg beperkt en spreken deels voor zich, maar hier voor de nieuwsgierigen.

• Ten opzichte van het InfoQ artikel is elk item/checkbox vertaald naar het Nederlands.
• Elk checkpunt nu een eigen code (bv. CO-003), die kort de categorie en het niveau aangeeft.
• Om het op één pagina te laten passen is de grote tabel opgesplitst in twee tabellen; één met niveaus 0 t/m 2 voor het gewenste niveau tijdens theorie deel van de course fase (1e 5 weken).
• Het streefniveau 2 'Gemiddeld' komt dus in beide tabellen voor als indicatie/koppeling tussen de twee. Tabel 2 is met niveaus 2 t/m 4 voor verdere verdieping in onderzoek, BP en het grote project. Vanaf base niveau 0 naar 2 doe je in de course fase als het goed is.

Tot slot zijn de volgende checkpoints in het CDMM toegevoegd:

• CO-206 Trunk based development - In lijn met punt 'CO-201 *minimale branching' is het logisch dat developers in versiebeheer zoveel mogelijk op de trunk werken (bv. main). Zie verder het artikel hierover uit 2018 op InfoQ hierover, 5 jaar na het CDMM artikel :) (InfoQ, 2019)
• Punt DB wijzigingen in VCS is verplaatst vanuit categorie 'Ontwerp & Architectuur' naar 'Build & Deploy' als BD-105 in lijn met de overige hogere checkpoints rondom 'db' zoals 'Automatiseer meeste DB wijzigingen* die ook in deze categorie staan. Deze hangen meer samen met automatiseren van deploys met pipeline en versiebeheer standaarden dan met de applicatie architectuur. Wel kun je argumenteren dat het gebruik van een ORM tool met migrations wel weer deels een (software) design of architectuur keuze is. Wel een ADR waard in ieder geval. Dan zouden BD-303 en BD-402 juist naar de categorie OA moeten, maar i.v.m. consistentie doen we dit niet.
• Verder nog geen punten. Suggesties zijn welkom, mits natuurlijk niet dubbelop met bestaande punten.

Gebruik checkpunten voor self assessments

De checkpunten ga je gebruiken in de weekopdracht en beroepsproduct, maar het is wel de bedoeling naast de code OOK de naam op te nemen in je eigen product documentatie, toelichting bijdrage team en dergelijke. Dus NIET enkel de code, want dan wordt het erg cryptisch (en moet de lezer dit weer opzoeken).

Bijvoorbeeld:

Het gezamenlijk zelf komen tot een besluit tijdens de sprint retrospective — in plaats van naar de PO te kijken voor een besluit — zien wij als voorbeeld van CDMM CO-206 - Decentrale besluitvorming). Dit toont aan dat wij als team al voldoende scoren op criterium Cultuur en Organisatie.

Op een eventuele vraag van de beoordelaar waarom jullie dan nog niet 'handelen op metrics' (C0-203) moeten je dan zelf idealiter een antwoord formuleren (wellicht is "Promotheus doen we pas in week 5" een goede verdediging ;))

Een verdere toelichting op de categorieën en niveaus vind je hieronder. Of vraag ernaar tijdens de lessen!

C. Mapping van de 'CDMM checkboxes' op de weekthema's/-opdrachten

Tijdens de lesweken in de course fase richt je je in opdrachten vooral op stappen Basis en Beginner. Tijdens het onderzoek en DevOps BP ontwikkeling (laatste 3 weken) ga je je als het goed is ontwikkelen naar hoger niveau een of manier criteria (maar tenminste vormbehoud).

Hieronder een klein opzetje van de mapping. Merk op dat het merendeel van de checkboxes nog ingedeeld moet worden. Waarbij je sommige in twee of meer categorieen kunt/moet indelen (zoals BD-207 'standaard proces voor alle omgevingen' in containerization en Continuous Deployment en OA-103 in containerization en devSecOps).

• Wk1 - GitOps: CO-003, BD-001 Code in versiebeheer, BD-103 Handmatige tags en versies, BD-201 Auto triggered builds (commit hooks), TV-001 Automatische unit tests, IR-102 Statische code analyse, TV-201 Automatische component test (geisoleerd), ...
• Wk2 - Containerization: OA-103 (3rd party) library management, BD-203 Build once deploy anywhere, BD-204 Automatiseer meeste DB wijzigingen, BD-206 , BD-401
• Wk3 - Continuous Delivery/BDD: CO-001, CO-101, BD-205, BD-206, IR-101, IR-202, TV-301 ...
• Wk4 - Orchestration/DevSecOps: OA-201 Geen of minimale branching, TV-002, TV-303, TV-304, OA-103, ...,
• Wk5 - SlackOps/DDD: IR-001, IR-002, IR-101, IR-301, OA-502... / IR-201, OA-501

D. Beoordelingsmomenten/toetsen

De beoordeling van dit beroepsproduct gebeurt op basis van 3 onderdelen. Deze komen langs twee beoordelingsmomenten; een Productdemo en een Code review. Hier een overzicht met ook beoordelingscriteria per onderdeel.

1. Productdemo a. Het tonen van het product en het updaten en live monitoren ervan tijdens een korte teamdemonstratie voor beoordelaar(s)/opdrachtgever
2. Code review a. Product en code/config review: Langer overleg met alleen team en beoordelaar(s):
   • toelichting indididuele bijdrage
   • vragen van beoordelaars
   • bespreking van jullie self assessment b. Kwaliteit van proces, README en de verdere achterliggende documentatie
   • verloop sprints en Scrum ceremonies
   • doornemen scrumborden, issues, user stories, traceerbaarheid wijzigingen via issues, commit messages, pull requests en review opmerkingen
   • doornemen/toetsen README en begrijpelijkheid documentatie (C4 + UML en overige diagrammen en (verpliche) tekstuele toelichting)

Hieronder geven subsectie E1, E2 en E3 verdere toelichting van respectievelijk Productdemo en Code Review en tot slot de wegingsfactoren o beter gezegd dat er juist geen harde/kwantitatieve wegingsfactoren zijn.

D1. Toelichting Productdemo

De productdemo duurt circa een kwartier en daarna max een kwartier vragen. De presentatie gebeurt voor de beoordelaars en in principe met aanwezigheid van de andere teams NIET met aanwezigheid andere teams. Omdat jullie in principe op basis van een redelijk bekende product hoef je aan introductie hiervan niet veel tijd te bestenden en licht je vooral je eigen uitbreiding hiervan toe, en demo't deploy van product increment en monitoring hiervan.

Voordat de demo is doe je met het hele team een self assessment van het gemaakte DevOps product en gevolgde proces en vult in een self-assessment.md voor alle 5 BC's een cijfer in op basis van niveaubeschrijvingen in de rubric in. Je schrijft hierbij ook een argumentatie voor de invulling, met enkele steekwoorden per BC en ook een of meer paragrafen voor de eindcijfer.

Bij beoordeling geldt dat alle te beoordelen zaken aanwezig zijn in ingeleverde beroepsproduct en ook in je documentatie te vinden zijn. Je werkt dus NIET in Word documenten, maar in tekst en markdownbestanden geintegreerd samen bij de broncode en configuratiebestanden.

Merk op dat de beschrijvingen van de 'lagere niveaus', basis, en beginner niet per se tekortkomingen beschrijven, maar ladders zijn op een trap die je moet nemen richting een voldoende en hopelijk zelfs goed cijfer. Op een aantal criteria zit je gelukkig wel al direct op een 6 door bijvoorbeeld gezamenlijke backlog voor Dev&Ops te gebruiken en een Test en/of Behaviour Driven aanpak te gebruiken.

Als gezegd moet je alle belangrijke zaken, zoals behaalde non functional requirements, of je proces als DevOps team ook zelf kort beschrijven in je documentatie. Je moet ook weten waar je zelf staat. De niveaubeschrijvingen zijn geen kant en klare recepten, dus je moet zelf ook een interpretatie hiervan doen en imvulling. Bij twijfel stem zaken - als het goed is vooraf - af met de beoordelende docent(en). Het expert (=extreem) niveau dat bij een 10 en hierbij ga je above en beyond, dus moet je ook zelf aangeven waarom je op het niveau zit.

D2. Toelichting Code Review

Bij een tweede langer assessment met alleen de docenten en je team gaan we ook in op kwaliteit code, match configuratie met infrastructuur model en gewenste NFR's? Als intro hiervoor bespreken jullie de grove rol- en werkverdeling en elk teamlid geeft toelichting van eigen bijdrage in het product (minstens 1 bijdrage waar je trots op bent, en kwaliteit kunt beargumenteren en een stuk werk waar je concrete verbeterpunten kunt noemen).

De kwaliteit van de README beoordelen docenten bijvoorbeeld door terplekke zelf de code te pullen uit versiebeheer en containers of clusters te runnen o.b.v. jullie README. En daarnaast te bekijken of documentatie voldoende aangrijpingspunten biedt voor nieuwe developer in team om het product snel te begrijpen en aan verder te bouwen.

Voor individuele beoordeling geef je verantwoording van je eigen bijdrage in het groepsproduct en bv. aan de hand van je markdown document ook meer details van het toepassen van de onderzochte technologieen uit de onderzoeksweek. Als gezegd hebben deze tools/technologieen hopelijk een positieve uitwerking op je eindproduct gehad. Denk aan verbeterde/makkelijkere monitoring, hogere productiviteit, betere security, betere code kwaliteit, geautomatiseerde pipeline etc.

D3. Eindcijferbepaling en wegingsfactoren

Tot slot nog evenover de weging; om dit EXPLICIET te maken: er is GEEN hard voorgeschreven weging tussen de 5 beoordelingscriteria om tot een eindcijfer te komen. Normaliter zullen alle vijf de criteria even zwaar wegen, en is er vaak een lijn qua product. En geeft een onvoldoende op een aspect reden tot twijfel. Maar het gaat meer om je eigen beoordeling en - vooral - beargumentering hiervan. Daarom moet je ook een self assessment doen; zie onder.

Het kan zijn dat sommige aspecten minder van belang waren in jullie opdracht en op zichzelf onvoldoende waren. Maar het overall toch voldoende was doordat een ander aspect buitengewoon goed is gedaan, of zaken door externe en niet te voorspellen zaken juist erg tegenvielen.

Merk ook op dat het eindproduct zelf geen eigen cijfer krijgt. Dit is bewust (dit is overigens tijdens projectblok anders, waar de opdrachtgever ook een deelcijfer geeft). Geen cijfer voor eindproduct betekent natuurijk NIET dat je geen product increment moet hebben. Dit is verplicht. Maar we willen niet dat je inzet op heel complexe functionaliteit en daarbij de DevOps basics uit het ogen verliest. Of bv. logging of monitoring aan de kant schuift. Maa zonder product (increment) is er geen proces. En beter product en logische 'bedrijfswaarde' geeft meer gelegenheid DevOps skills te tonen en een betere demo en leidt indirect toch tot een hoger cijfer.

Bijvoorbeeld een groter product increment of uitgebreide refactoring in bestaande code of opsplitsen van microservice in 1 container in 2 aparte, geeft ook een langer commit spoor, meer unit tests, een aanleiding voor extra Q&A omgeving, een demo canary deploy voor subfunctionaliteit I, een A/B test van een andere functionaliteit, data migratie van feature X, en (zelf onderzochte) InfraStructure As Code configuratie voor microservice Z. Een groter product increment geeft natuurlijk ook meer aanleiding voor een complexere architectuur. Ga je voor een simpele CRUD microservice, of kies je juist complexe logica die ook een 'domain driven' ontwerp vraagt, met wellicht caching in miroservice en synchronisatie tussen microservives, een event-driven en/of CQRS aanpak met eventual consistentie, inzet van een message broker etc.

E. Speciale noot over (geautomatiseerd) testen

¹ Merk tot slot op dat het instapniveau (dus 2) niveau qua Test en Verificatie direct 'code is onder test', dus geautomatiseerde tests. Terwijl dit in het beroepsveld lang nog niet bij alle bedrijven gebeurt. In de course gaan we in op BDD (ook wel ATDD = Acceptance Test Driven Design of 'Specification by Example' genoemd), waar ISM studenten ook nog een rol bij kunnen spelen in het opstellen. Maar er is in de minor binnen contacturen niet de tijd om TDD 'vanaf de grond' aan te leren. Maar TDD en gerelateerde patterns en principe als Arrange, Act, Assert (AAA) en Red, Green Refactor veronderstellen we wel als bekend bij developers. Zorg dat je hier ook mee geoefend hebt, of alsnog oefent!

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

De grondlegger van de term Continuous Integration Martin Fowler hamert in vele van zijn blogs op TDD aanpak en legt in blog met titel 'Is high quality software worth the cost?' aan dat deze vraag op een verkeerde veronderstelling berust, omdat kwaliteitssoftware juist goedkoper is om te onderhouden in plaats van duurder (zie figuur 1).

Figuur 1: High (internal) quality software is goedkoper i.p.v. duurder! Aldus Martin Fowler (2019).

In deze lijn trekken in de DevOps wereld over het algemeen door, bv. Continuous Delivery voorman David Farley (van het gelijknamige 'seminal' boek). Met 'goed' bedoelen we hier:

• behoorlijke test coverage, in ieder geval van complexe code (hoge cyclomatische complexiteit)
• leesbare testcode met cyclomatische complexiteit van 1)
• gericht op gedrag en testen van interface i.p.v. implementatie details
• en zonder 'unit testing anti patterns' (zoals 'Liar', 'Excessive setup', 'The giant' en 'The mockery' zie deze video van David Farley).

Bronnen

• Boström, P & Palmbor., T 6 februari 2013. The Continuous Delivery Maturity Model, geraadpleegd 13-1-2021 op https://www.infoq.com/articles/Continuous-Delivery-Maturity-Model
• Fowler, M. 19 mei 2019, Is high quality software worth the cost. Geraadpleegd 20-10-2021 op https://martinfowler.com/articles/is-quality-worth-cost.html
• InfoQ (2018). Trunk Based Development as a Cornerstone for Continuous Delivery. InfoQ.com. Geraadpleegd 5-9-2024 op https://www.infoq.com/news/2018/04/trunk-based-development/

Beoordeling Individuele bijdrage

• Datum: 11 okt 2021
• Auteur: Bart van der Wal

1. Inleiding: Verantwoording eigen bijdragen

Naast je beoordeling als team voor het samen gemaakte product krijg je ook een individueel cijfer op basis van jou bijdrage aan dit product. Dit gebeurt zowel tijdens beroepsproduct en voor je product uit blok 2.

Je hoeft tijdens het project geen uitgebreid verslag te schrijven, en sowieso geen Word documenten, zoals in sommige andere projecten. Maar wel moet elk groepslid wel een eigen markdown bestand toevoegen en bijhouden (direct) in de docs folder van het team repository/project. Hieronder het template. Dit template bevat de volgende 9 kopjes. Bij elk kopje kort vermeld de competenties uit de OWE of 'devops maturity' aspecten die hier in ieder geval bij horen:

1. Code/platform bijdrage

   • DevOps-1 Continuous Delivery
   • CDMM: Design & Architecture
   • CDMM: Test & Verification

2. Bijdrage app configuratie/containers/Kubernetes

   • DevOps-2 Orchestration
   • DevOps-4 Containerization
   • CDMM: Design & Architecture

3. Bijdrage versiebeheer, CI/CD pipeline en/of monitoring

   • DevOps-3 GitOps
   • DevOps-5 SlackOps
   • CDMM: Information & Reporting
   • CDMM: Test & Verification
   • CDMM: Build & Deploy

4. Onderzoek

   • DevOps-6 Onderzoek

5. Bijdrage code review/kwaliteit anderen en security

   • DevOps-4 DevSecOps
   • CDMM: Culture&Organization
   • CDMM: Test & Verification

6. Bijdrage documentatie

   • CDMM: Design & Architecture
   • DevOps-6 Onderzoek

7. Bijdrage Agile werken, groepsproces, communicatie opdrachtgever en soft skills

   • DevOps-7 Attitude*
   • CDDM: Culture & Organization

8. Leerervaringen

   • DevOps-7 Attitude
   • CDDM: Culture & Organization

9. Conclusie & feedback

   • DevOps-7 Attitude

Dit document dient als bewijslast richting beoordelaars op meer afstand, maar ook voor je eigen overzicht en ter referentie tijdens de groepssessie voor beoordeling van de individuele bijdrages.

Om een basisvulling te vereisen maar ook al te grote omvang van het document te beperken ivm beoordeelbaarheid, vermeldt het template wat minimum- en maximumaantallen. Dit bestand houdt je bij tijdens het hele project.

Hieronder in sectie 2 wat eisen en richtlijnen over het 'invullen' van het template. In sectie 3 volgt het template zelf, om te copy-pasten naar je eigen repo. In sectie 4, 5 en 6 daarna nog wat achtergrondinformatie bij de individuele beoordeling, de individuele delta die dit geeft op het groepscijfer respectievelijk de algemene beoordelingscriteria die hierbij relevant zijn.

2. Eisen en richtlijnen Individuele verantwoording

Hieronder de richtlijnen in 4 subsecties, maar deze lijst is al de TL; DR:

1. Zorg dat template teksten zo snel mogelijk weg zijn uit de templates, uiterlijk bij (en enige ;) tussentijdse beoordeling.
2. Zorg dat verantwoording ook tussentijds al leesbaar en compleet is (tussentijds eventueel TODO's voor jezelf)
3. Gebruik vrije tekst en bullets
4. Gebruik (semantische) linkteksten GEEN kale URL's.

2.1 Beoordelaar kijkt niet als er nog template teksten aanwezig zijn

Verwijder voor het inleveren alle template teksten! Zodat alleen de kopjes (en opgesomde competenties) overblijven!

De template teksten staat in de markdown als hulp. Maar aanwezigheid van deze (standaard) template teksten op het moment van beoordelen ziet de beoordelaar als een teken dat je nog niet klaar bent ermee bent. Dit heeft als gevolg dat hij/zij dus niet kan beoordelen. Niet (kunnen) beoordelen betekent een onvoldoende!

Vervang bijvoorbeeld <mijn-naam> bv. door Eliezer Yudkowsky. NB: Dus NIET <Eliezer Yudkowsky >; de angle brackets (< en >) zijn om templateteksten aan te geven, dus bij invullen moet je ze WEGhalen.

2.2 Ook leesbaar en compleet bij tussentijdse beoordeling

Bij tussentijdse toetsing heb je al een volledige en leesbare versie, met minstens de minimale aantallen. Richting de eindbeoordeling werk je deze verder bij, en schrapt evt. punten als je anders over het maximum aantal gaat en je inmiddels grotere/belangrijker zaken hebt. Of als je punten kunt samenvoegen onder 1 noemer (N.B. Punten zijn evt. terug te vinden via versie historie).

Dus je vult ook al een voorlopige eindoordeel in. En bijvoorbeeld hebt ook al de helft van de tips en tops.

Mocht je er tussentijds achterkomen dat onder een kopje nog te weinig of zelfs GEEN werk en/of links kunt geven, neem voor je zelf dan wat TODO's op, met een richting, zodat je in de 2e helft kunt zorgen dat je wel voldoende varieteit en breedte in je werk hebt.

2.3 Gebruik vrije tekst én bullets

TL; DR Dus: gebruik een combinatie van beschrijvende teksten en korte bullet lijsten met links naar werk in het met team gebruikte 'code management systeem' waarmee beoordelaar je werk kan verifieren.

De bedoeling van deze verantwoording is dat het korte tekstuele beschrijving is. Voor structuur gebruik je hierbij ook bullets. Maar je gebruikt NIET alleen maar bullets, of alleen maar paragrafen. Je gebruikt een combinatie. Typisch is een paragraaf dan een inleiding bij een bullet lijst, zoals Qua Kubernetes configuratie deed ik het volgende. Of een toelichting bij iets interessantes. Schrijf ook een korte inleiding.

2.4 Gebruik linkteksten

• Maak van links shortlinks, dus met goede linktekst en niet de hele originele URL’s (die nemen anders groot deel van je documentatie in beslag, dat is ongewenst)
• Maak deze links ook naar bv. code diffs of pull requests i.p.v. direct naar volledige bestanden/folders in versiebeheer met integrale stukken code die van iedereen in het team kunnen (en horen!) te zijn.
• Plaats ook opmerkingen in pull requests (review opmerkingen) en github issues ().

Het agile principe van face-to-face contact is ook belangrijk, maar stem niet alles alleen maar mondeling af zorg voor de traceerbaarheid en beoordeelbaarheid door externen. Zo heeft groepsgenoot ook iets om op terug te vallen na mondeling afstemmen (of deze notuleert zelf mondling overleg in issue).

Als je dit onverhoopt tijdens het project te weinig gedaan hebt, kun je alsnog dit documenteren. In je markdown zelf maakt deze wellicht te groot, maar dan kan het in een taak/issue waar je in markdown naar linkt, of in de wiki o.i.d. (hier hebben jullie hopelijk ook team standaard voor, en anders kun je die wellicht met terugwerkende kracht opstellen, in kader van overdracht naar anderen, nu jullie dit project gaan verlaten).

Dus vervuil je markdown niet met hele lange URL links, maar kort deze in, of - beter nog - maak een linktekst die echt semantisch is, en ook thuishoort in een lopende tekst. In de tabel hieronder drie voorbeelden.

Mwegh...	Okee.	Top!

3. Markdown template individuele bijdrage

# Eigen bijdrage <mijn-naam>
 
Als deliverable voor de individuele bijdrage in het beroepsproduct maak een eigen markdown bestand `<mijn-voornaam>.md` in je repo aan met tekst inclusief linkjes naar code en documentaties bestanden, pull requests, commit diffs. Maak hierin de volgende kopjes met een invulling.
 
Je schrapt verder deze tekst en vervangt alle andere template zaken, zodat alleen de kopjes over blijven. **NB: Aanwezigheid van template teksten na inleveren ziet de beoordelaar als een teken dat je documentatie nog niet af is, en hij/zij deze dus niet kan of hoeft te beoordelen**.
 
Je begin hier onder het hoofdkopje met een samenvatting van je bijdrage zoals je die hieronder uitwerkt. Best aan het einde schrijven. Zorg voor een soft landing van de beoordelaar, maar dat deze ook direct een beeld krijgt. Je hoeft geen heel verslag te schrijven. De kopjes kunnen dan wat korter met wat bullet lijst met links voor 2 tot 4 zaken en 1 of 2 inleidende zinnen erboven. Een iets uitgebreidere eind conclusie schrijf je onder het laatste kopje.


## 1. Code/platform bijdrage

Competenties: *DevOps-1 Continuous Delivery*

Beschrijf hier kort je bijdrage vanuit je rol, developer (Dev) of infrastructure specialist (Ops). Als Developer beschrijf en geef je links van minimaal 2 en maximaal 4 grootste bijdrages qua code functionaliteiten of non-functionele requirements. Idealiter werk je TDD (dus ook commit van tests en bijbehorende code tegelijk), maar je kunt ook linken naar geschreven automatische tests (unit tests, acceptance tests (BDD), integratie tests, end to end tests, performance/load tests, etc.). Als Opser geef je je minimaal 2 maximaal 4 belangrijkste bijdragen aan het opzetten van het Kubernetes platform, achterliggende netwerk infrastructuur of configuration management (MT) buiten Kubernetes (en punt 2).
 
## 2. Bijdrage app configuratie/containers/kubernetes

Competenties: *DevOps-2 Orchestration, Containerization*
 
Beschrijf en geef hier links naar je minimaal 2 en maximaal 4 grootste bijdragen qua configuratie, of bijdrage qua 12factor app of container Dockerfiles en/of .yml bestanden of vergelijkbare config (rondom containerization en orchestration).

## 3. Bijdrage versiebeheer, CI/CD pipeline en/of monitoring

Competenties: *DevOps-1 - Continuous Delivery*, *DevOps-3 GitOps*, *DevOps-5 - SlackOps*

Beschrijf hier en geef links naar je bijdragen aan het opzetten en verder automatiseren van delivery pipeline, GitOps toepassing en/of het opzetten van monitoring, toevoegen van metrics en custom metrics en rapportages.

NB Het gebruik van *versiebeheer* ((e.g. git)) hoort bij je standaardtaken en deze hoef je onder dit punt NIET te beschrijven, het gaat hier vooral om documenteren van processtandaarden, zoals toepassen van een pull model.

## 4. Onderzoek

Competenties: *Nieuwsgierige houding*

Beschrijf hier voor het Course BP kort je onderzochte technologie met een link naar je blog post, of het toepassen ervan gelukt is en hoe, of waarom niet. Beschrijf evt. kort extra leerervaringen met andere technologieen of verdieping sinds het blog. 

Tijdens het grote project beschrijf je hier onderzoek naar het domein en nieuwe onderzochte/gebruikte DevOps technologieën. Wellicht heb je nogmaals de voor blog onderzochte technologie kunnen toepassen in een andere context. Verder heb je nu een complex domein waar je in moet verdiepen en uitvragen bij de opdrachtgever. Link bijvoorbeeld naar repo's met POC's of, domein modellen of beschrijf andere onderwerpen en link naar gebruikte bronnen.

Als de tijdens course onderzochte technologie wel toepasbaar is kun je dit uiteraard onder dit punt noemen. Of wellicht was door een teamgenoot onderzochte technologie relevant, waar jij je nu verder in verdiept hebt en mee gewerkt hebt, dus hier kunt beschrijven. Tot slot kun je hier ook juist een korte uitleg geef over WAAROM  jouw eerder onderzochte technologie dan precies niet relevant of inpasbaar was. Dit is voor een naieve buitenstaander niet altijd meteen duidelijk, maar kan ook heel interessant zijn. Bijvoorbeeld dat [gebruik van Ansible in combi met Kubernetes](https://www.ansible.com/blog/how-useful-is-ansible-in-a-cloud-native-kubernetes-environment) niet handig blijkt. Ook als je geen uitgebreid onderzoek hebt gedaan of ADR hebt waar je naar kunt linken, dan kun je onder dit kopje wel alsnog kort conceptuele kennis duidelijk maken.
 
## 5. Bijdrage code review/kwaliteit anderen en security

Competenties: *DevOps-7 - Attitude*, *DevOps-4 DevSecOps*

Beschrijf hier en geef links naar de minimaal 2 en maximaal 4 grootste *review acties* die je gedaan hebt, bijvoorbeeld pull requests incl. opmerkingen. Het interessantst zijn natuurlijk gevallen waar code niet optimaal was. Zorg dat je minstens een aantal reviews hebt waar in gitlab voor een externe de kwestie ook duidelijk is, in plaats van dat je dit altijd mondeling binnen het team oplost.
 
## 6. Bijdrage documentatie

Competenties: *DevOps-6 Onderzoek*

Zet hier een links naar en geef beschrijving van je C4 diagram of diagrammen, README of andere markdown bestanden, ADR's of andere documentatie. Bij andere markdown bestanden of doumentatie kun je denken aan eigen proces documentatie, zoals code standaarden, commit- of branchingconventies. Tot slot ook user stories en acceptatiecriteria (hopelijk verwerkt in gitlab issues en vertaalt naar `.feature` files) en evt. noemen en verwijzen naar handmatige test scripts/documenten.
 
## 7. Bijdrage Agile werken, groepsproces, communicatie opdrachtgever en soft skills

Competenties: *DevOps-1 - Continuous Delivery*, *Agile*

Beschrijf hier minimaal 2 en maximaal 4 situaties van je inbreng en rol tijdens Scrum ceremonies. Beschrijf ook feedback of interventies tijdens Scrum meetings, zoals sprint planning of retrospective die je aan groespgenoten hebt gegeven.

Beschrijf tijdens het project onder dit kopje ook evt. verdere activiteiten rondom communicatie met de opdrachtgever of domein experts, of andere meer 'professional skills' of 'soft skilss' achtige zaken.
  
## 8. Leerervaringen

Competenties: *DevOps-7 - Attitude*

Geef tot slot hier voor jezelf minimaal 2 en maximaal **4 tops** en 2 dito (2 tot 4) **tips** á la professional skills die je kunt meenemen in toekomstig project, afstuderen of wellicht zelfs verdere loopbaan (de 'Transfer' uit STARRT). Beschrijf ook de voor jezelf er het meest uitspringende hulp of feedback van groepsgenoten die je (tot dusver) hebt gehad tijdens het project.

## 9. Conclusie & feedback

Competenties: *DevOps-7 - Attitude*

Schrijf een conclusie van al bovenstaande punten. En beschrijf dan ook wat algemener hoe je terugkijkt op het project. Geef wat constructieve feedback, tips aan docenten/beoordelaars e.d. En beschrijf wat je aan devops kennis, vaardigheden of andere zaken meeneemt naar je afstudeeropdracht of verdere loopbaan. 

4. Werkwijze beoordeling individuele bijdrage

Voor je individuele bijdrage in het project krijg je ook een beoordeling.

4.1 Input voor beoordeling

Basis hiervoor is de input van je teambegeleider(s), en evt. observaties van de klant/opdrachtgever tijdens Scrum ceremonies of daarbuiten of andere door beoordelaars belangrijk gevonden punten. De inbreng tijdens Productdemo of de Review sessie kan ook doorslag geven als je ervoor nog te weinig zichtbaar was. Uiteraard weegt ook mee het correct en voor externen ook leesbaar en begrijpelijk invullen van bovenstaand template met je verantwoording van je individuele bijdrage.

4.2 Groepssessie individuele beoordeling

De uiteindelijke individuele beoordeling gebeurt n.a.v. een groepssessie. Dit klinkt wellicht tegenstrijdig, want je focust in de verantwoording op eingen werk, maar we gaan er vanuit dat je toelichting bekend is bij teamgenoten en geen verantwoording. Omdat samenwerking met groepsgenoten en bv. het reviewen van elkaars werk, of anderszins samenwerken centraal staat bij DevOps. Tijdens de sessie geef je ingevulde tekst toelicht. Deze meeting duurt een half uur tot een uur afhankelijk van je groepsgrootte. Je hebt hierbij ongeveer 5 minuten voor je eigen werk. Deze sessie plan je in met je begeleiders/beoordelaars. De begeleider vraagt tijdens deze sessie bijvoorbeeld het volgende:

• Waar ben je het meest trots op van je bijdragen aan het teamproduct?
• Waar heb je nog het minst laten zien?
• Vervolgens lopen we samen snel door je factsheet heen

Aan het eind van de sessie geeft de beoordeleer aan wat je delta op het groepscijfer is.

Als teamlid mag je opmerkingen/input geven, maar we proberen discussies te bewaren voor andere contactmomenten.

4.3 Gebruik links

Naast de tekst zelf is natuurlijk de kwaliteit van het daarin gelinkte bronmateriaal (zorg dat de links zelf ook werken, en bv. wijzen naar een diff of review van eigen werk, i.p.v. naar werk van anderen). Zorg ook dat het presentabel is door GEEN kale lange URL's te geven, maar de URL's zelf waar mogelijk in te korten maar ook netjes achter een link te stoppen met korte maar duidelijke linktekst in een duidelijke en actief geschreven zin (of herschrijf).

5. Delta op teamcijfers

Je eindcijfer is het groepscijfer en nog individuele 'delta' hierop. Deze delta is in principe 0, dus dat betekent dat je eindcijfer hetzelfde is als het groepcijfer. Maar als beoordelaars aanleiding hebben kunnen deze een delta geven die varieert van -1 tot +2 op het teamcijfer. Ook geldt dat als je als teamlid geheel niet of duidelijk te weinig hebt bijgedragen, of je bijdrage niet voldoende kunt verantwoorden, dan is je eindcijfer een onvoldoende, ongeacht het teamcijfer. Dit laatste betekent dus dat je het project een volgende editie over moet doen. Hetzelfde geldt uiteraard als na toepassen van een delta je eindcijfer onder de 5,5 zit.

• 2 Project niet afgerond
• 4.5 Project gedaan maar onvoldoende bijgedragen (geen vormbehoud courses) en/of deze bijdrage niet voldoende verantwoord
• -1 Op aantal punten tekort geschoten, maar wel significante bijdrage
• -0,5 Op één of enkele punten tekortgeschoten op verwachte input of toegezegde bijdrage
• +0 Project goed meegewerkt, gezorgd voor significante bijdrage en kwaliteit en vormbehoud van course
• +0,5 Erkenning van belangrijke bijdrage op een aspect van het teamproduct of -proces
• +1 Belangrijke extra invloed qua kwantiteit of kwaliteit van teamproduct binnen het team op één of enkele punten
• +2 Op een aantal punten een essentiële positieve extra invloed qua kwaliteit, kwantiteit van werk

Om bovenstaande wat concreter te maken hieronder enkele (fictieve) beschrijvingen van projectsituaties en de hieruit voortkomende beoordeling.

5.1 Voorbeeld 1

Een team heeft als teamcijfer een 7 gehaald met een weinig opvallend project met wel een enthousaste en duidelijk einddemo. Eigenlijk al het gevraagde zat erin, zij het minimaal. Teamlid A heeft een belangrijke invloed gehad bij de realisatie van de database, en is 'above and beyond' gegaan en krijgt een 7+1=8. Teamlid B heeft steady gecodeerd, maar heeft geen enkele verslaglegging gedaan en kan achteraf ook onvoldoende terugvinden in aangemaakte issues of commit opmerkingen om dit nog te fixen voor de inlever deadline. Een 4.

5.2 Voorbeeld 2

Een team heeft een 6 gekregen. In dit team is Teamlid X in week 2 helaas uitgevallen (een 1). Het security aspect missen zij geheel, want heeft verder niemand opgepakt ondanks dat dit teamverantwoordelijkheid is. Wel is er een nieuw microservice en wijzigingen in back-end en front-end met noSQL storage. Teamlid Y heeft een bestaand issue nooit gefixt, hoewel dit wel met hem is afgesproken omdat dit bij zijn expertise hoorde. Achterliggende reden was dat zijn technologie toch niet in bleek te passen in het beroepsproduct en hierdoor was hij gedemotiveerd.

De team beslissing bij sprint 2 om dit te laten vallen en te documenteren als ADR was hij het eigenlijk niet mee eens. Maar dat durfde hij toen niet te zeggen. Omdat hij achter de schermen bleef 'doormodderen' kwam hij een week onvoldoende aan zijn issues toe. Gelukkig kon hij hier wel op reflecteren en heeft op de front-end in de week erna nog goed bijgedragen: (6-0.5 = 5.5).

Teamlid Z heeft alle issues van X opgelost, en ook de hele front-end opgezet, en hierbij ook een BDD aanpak gerealiseerd waardoor vanuit de front-end de hele applicatie geacceptatest kan worden: 6+2 = 8.

6. Beoordelingscriteria

Bij de beoordeling is uitgangspunt dus een ingevulde individuele bijdrage en uiteraard ook alles wat erachter zit qua product/configuratue en documentatie in gitlab/versiebeheer. De beoordelaars hebben verder ook indrukken beoordelaars tijdens SCRUM sessies en dergelijke. Tijdens het project hoef je niet alles te doen wat in de course behandeld is, maar je hebt hier wel gebruik van gemaakt en toont vormbehoud op de competenties uit de course fase (zoals ook vermeld in individuele bijdrage):

• DevOps-1 Continuous Delivery
• DevOps-2 GitOps
• DevOps-3 Containerization
• DevOps-4 DevSecOps
• DevOps-5 SlackOps
• DevOps-6 Onderzoek
• DevOps-7 Attitude

Verder kunnen beoordelaars ook algemene teamcompetenties meenemen zoals:

• Focus op kwaliteit en kwantiteit van het werk
• Pragmatisch houding (KISS) en rol pakken
• Teamgenoten helpen
• Kritische houding, focus op testen, security en reliability
• Aanspreekbaar zijn en verantwoordelijkheid nemen
• Nieuwsgierige en onderzoekende houding

FAQ Eindopdracht

Onderzochte technologie toepassen in beroepsproduct

Vraag: Ik kan mijn beoogde onderzochte technologie toch niet toepassen. Kan ik nu alsnog een voldoende halen voor het project?

Antwoord 1

Dit kan gebeuren. Want als je vantevoren al 100% wist dat de gekozen technologie ging werken dan was je gekozen technologie wellicht niet spannend genoeg...

Of je alsnog een voldoende haalt is afhankelijk van je motivering hierbij. Als je moet kort vooronderzoek de problemen al had kunnen voorzien, dan had je de technolgoie niet moeten onderzoeken. Het idee van praktisch onderzoek is wel dat je de resultaten gebruikt om om het toe te passen. Onderzoek alleen voor theorie doen we niet in dit project/vak (elders heeft dit zeker en plaats...)

Idealiter merk je aan het eind van het onderzoek al dat het onderzochte wellicht toch niet past. Soms stuit je op een bug of moeilijk te voorzien integratie probleem. Gebruik alsnog je geschreven blog post als referentie, mogelijk voor een in de toekomst. Of als genoemd/overwogen alternatief voor een wel gebruikte technologie of aanpak (denk aan decision forces diagram). Als er een bug is, geef dan een referentie naar documentatie waar dit staat. Of een issue in open source repo. Mocht deze er niet zijn, dan maak je deze natuurlijk zelf even aan, om de community al wat verder te helpen.

Als de enige reden dat je het niet toegepast is dat je hier geen tijd voor had is dit in principe niet geldig. Je moet dan althans in je documentatie nog een beschrijving geven hoe het wel toegepast kan worden. Bij wel voldoende tijd. Geef een oplossingsrichting.

Unieke technologie

Vraag: Ik wil dezelfde technologie onderzoeken als mijn teamgenoot

Antwoord 2

Dat mag niet :|. Het is de bedoeling je eigen specialisatie te hebben en niet het geehl met zijn tween te doen. Uiteraard mag je elkaar wel helpen en verder samenwerken. Als het een grote tool of framework is waar je beiden één aspect of feature van wilt onderzoekn mag dit wel. Stem dan onderling gezamenlijke zaken af en zorg dat je ook een eigen aspect. Licht deze situatie ook kort toe in de inleiding van je blogpost en verwijs naar elkaars blog posts, met een quote of parafrase waaruit de lezer een idee heeft wat het is en wat de verschillen zijn.

Week 9 - Presentaties, herkansingen, transfer naar project blok 2

• Les 1 - Eindpresentaties
• Vrijdag: Minor DevOps Workshop Maarten van Golen MCPS

De volledige formele eisen, competenties en beoordeling staan in de de OWE.

De beoordeling van het beroepsproduct is in de vorm van een teampresentatie van het gebouwde product, en live deployment. Tot slot geef je hier ook de als team eerder vastgestelde self assessment op basis van het Continuous Delivery Maturity Model (CDMM). Met ook verbeterpunten en/of richtingen van evt. known issues.

Op een andere dag een meer inhoudelijke review meeting ook met het hele team, maar dan met van alle teamleden toelichting van eigen bijdrage in product en kwaliteit hiervan. Hierbij laat je ook documentatie zien zoals C4 diagrammen, Architecture Decision Records en een goeie README. Maar de mondelinge toelichting vinden we minstens zo belangrijk als 'comprehensive documentation'. Dit is vergelijkbaar met de beoordelingvorm in het grote project in blok 2. Je code moet zoveel mogelijk voor zichzelf spreken (the code IS the design). Maar gekozen technologieen moet argumentatie voor zijn (DRY vs YAGNI e.d.).

Na de presentaties is deze week ook de herkansingsmogelijkheid van theorietoetsen. En eind van de week kennismaking met de opdrachtgever.

Week 9 - Herkansings(totaal)toetsen

Als je voor één of meer deeltoetsen een onvoldoende had en je cijfer wilt ophalen, of zelfs als je al voldende had, maar je cijfer gewoon wilt ophalen, heb je op deze dag een totaaltoets voor zowel de course Dev als de course DevOps. Je moet je wel vantevoren aanmelden via iSASOsiris. Het lokaal navragen bij de docent (of evt. in iSAS).

• Oefendeeltoets DevOps 2

NB November 2023: De grote set Kubernetes oefenvragen uit Kahoots zijn ook in deze oefentoets gezet, i.v.m. lagere toegankelijkheid van Kahoots.

Vrijdag 3 november 2023 11:30-13:00 (lokaal: C1.06)

• 11:30 Lokaal open, intro en regels
• 11:35 TheorieToets Dev: Linux, C4, RabbitMQ
• 12:05 Einde/Pauze
• 12:15 Theorietoets DevOps: GitOps t/m SlackOps en DDD t/m EDA...
• 12:45 Einde/Evt. kort nabespreken desgewenst
• 13:00 Einde

Toetsregels

Cesuur 70%: max 12 fout voor voldoende (5,5).

• Eén punt voor iedere 'multiple choice' vraag (tenzij anders aangegeven).

  • Bij multiple choice is slechts 1 antwoord goed (of 1 antwoord is 'het beste').
  • Voor open vragen is het aantal punten aangegeven.

• Er zijn geen hulpmiddelen teogestaan zoals boeken, spiekbriefjes, websites of communicatiemiddelen toegestaan.

  • Je mag alleen 1 browser open hebben met 1 tabblad (namelijk die met daarin deze online toets)!
  • Voor de start van de toets graag je rugzak of tas met je telefoon, smartwatch en/of andere devices voorin de klas leggen.
  • Evt. gebruikt kladpapier moet je bij het verlaten van de klas ook inleveren.

• Je mag het lokaal verlaten pas na de helft van de toetstijd, en dan laptop en rugzak achter laten in de klas.

• Mensen met 'extra tijd' regeling kunnen max 50% extra tijd krijgen. I.v.m. bepertke lestijd en nabespreking gaat dit wel ten koste van eventuele pauzetijd tussen 2 toetsen door.

• Bij Digitale toetsen in Ans gaan via de Schoolyear safe browser

  • Sluit de toets na het starten NIET meer af, dit ziet Schoolyear als fraude, en dan sluit deze je buiten

• De digitale toets is 'Bring your own device', je moet Windows of macOS draaien (dus geen Linux, regel dan 'dual boot' of vraag anders tijdig een leenlaptop aan bij de HAN (dit kan via Osiris))

DevOps (voltijd)

"Let's do some major DevOps!"

In deze multidisciplinaire minor staat de moderne techniek DevOps centraal. In een DevOps-team werken developers en beheerders samen om nieuwe features van een applicatie te ontwikkelen, en tegelijkertijd de bestaande features draaiende te houden.

Hierbij is er veel aandacht voor het garanderen van een hoge beschikbaarheid van een applicatie. We gaan kijken naar loosely coupled micro services, event-carried state transfer, Docker, Kubernetes, RabbitMQ, unit testen, acceptatie testen, build- en release-pipelines, logging, monitoring, site reliability engineering, kort-cyclisch development en natuurlijk de samenwerking tussen Dev en Ops.

De minor bestaat uit twee gedeelten: een gedeelte met theorie en een kleinschalig project waarin zowel je theoretische als praktische kennis wordt voorbereid op het tweede deel: het uitvoeren van een grootschalige project voor een echte klant waarbij je je expertise optimaal kunt benutten. Beide delen worden verzorgd door de HAN en Info Support samen, waarbij de HAN vooral in het eerste en Info Support vooral in het tweede deal de lead zal nemen in de begeleiding.

Afhankelijk van het profiel dat je volgt, wordt aandacht besteed aan de volgende onderwerpen:

• Devops
• Test driven development
• Deployment-tooling (CD/CI-tools, containers, container orchestration)
• Management en beheer (configuration management, monitoring, logging, cloud providers)
• (Domain driven) design en design patterns
• OO-programmeren
• REST
• ORM
• Web- en applicatieservers
• Versiebeheersystemen (zoals Git)
• Operating systems
• Netwerken, security en protocollen
• Proxies, load balancers, firewalls

Leerdoelen

Na het volgen van deze minor beschik je over de theoretische en de praktische kennis om een continuous delivery-project in te richten en uit te voeren in een professionele organisatie.

Aanvullende informatie

Voor meer informatie:

info@han.nl | T (024) 35 30 500 van 09.00 tot 16.30 bereikbaar | www.han.nl

Contactpersoon minor

Ralph Niels E-mail: Ralph.Niels@han.nl

Inschrijven? Goed om te weten!

Bij populaire minoren vindt 3 tot 4 weken na het open gaan van de inschrijvingen een loting plaats áls er op dat moment meer inschrijvingen zijn dan beschikbare plaatsen. Bij de minoren waar nog plaats is, geldt daarna tot aan de sluiting van de inschrijfperiode: zodra een minor vol is, wordt deze gesloten, vol = vol.

Daarnaast geldt dat als het aantal aanmeldingen na drie weken ruim onder de norm ligt; deze minor mogelijk wordt teruggetrokken. Dus heb je interesse, meld je direct aan.

Schrijf je op tijd in!

Let op: Voor HAN studenten geldt dat zij zich, in geval van uitloten of geen doorgang van de eerste keuze NA de periode van besluitvorming (deze duurt ca. 3 weken), kunnen herinschrijven. Dit kan alleen op de dan nog beschikbare minoren die plaatsen vrij hebben.

Ook dan geldt: zodra een minor vol is, wordt deze gesloten, vol = vol.

Een goed overzicht van de HAN minoren kun je vinden in de minoren app! De app is bereikbaar via: http://www.minoren-han.nl/

Ingangseisen

Studenten HBO-ICT van de HAN die een development-profiel volgen of het profiel ISM volgen.

Toetsing

Er zijn voor beide courses 2 deeltoetsen (totaal 4 theorie toetsen). Verder zijn er wekelijkse verplichte oefeningen voor DevOps course ook oefeningen voor sommige Dev workshops. Verder is er een individueel onderzoek voor de Dev course waarvoor je een verslag moet schrijven (blogpost).

Tot slot is er een DevOps beroepsproduct waar je met een team 2 weken aan werkt en tot slot presenteert voor beoordelaars en ook individuele bijdrage aan toelicht tijdens een review sessie.

De toetsing is de standaard projecttoetsing met een tussentijds groepsbeoordeling en individuele beoordeling en hetzelfde op het eind. De beoordelingscriterie en eisen tijdens het project volgen begin van het project.

Zie details overweging en beoordeling in de OWE.

Rooster

Er wordt vanuit gegaan dat studenten van maandag t/m vrijdag beschikbaar zijn, dus bijbaantjes of andere vakken van maandag t/m vrijdag (9.00-17.45 uur) volgen is geen optie.

De roostering zal plaatsvinden zoals bij AIM gebruikelijk: in de coursefase 4 tot 6 maal per week een dagdeel les (verder zelfstudie) en in de projectfase 40 uur per week projectwerk.

Werkvormen

• Werkcolleges
• Projectopdracht

Deze tekst staat ook op kiesopmaat.nl (dd, 1 feb 2021)

DevOps tools (tech in deze minor (logo attributie)

Courses - Blok 1 bij AIM

• git
• Markdown
• Docker
• OpenNebula
• Kubernetes
• GitLab
• GiHub
• Java
• Cucumber
• RabbitMQ
• ELK
• npm
• Ansible
• DevOps schema
• DotNet core

Project - Blok 2 bij InfoSupport

• Argo
• Azure
• Azure DevOps
• React
• Java 11
• Docker
• Kubernetes
• Argo
• Micronaut (todo logo)

Logo's

DevOps lijst van concepten

Onderstaande tabel bevat een lijst van woorden, of — beter — concepten (want een concept bestaat soms uit meerdere woorden). De tabel bestaat nu vooral uit een toelichting op de checkpunten uit het CDDM beoordelingsmodel. Voor het beantwoorden van vaker terugkomende vragen zoals:

Wat wordt er bedoelt met het punt BD-203 - Build Once deploy anywhere?

Hoe dan ook, van deze termen moet je de betekenis kennen als je de minor hebt gevolgd. Alleen de uitleg in de tabel lezen is niet altijd voldoende voor goed begrip. Je moet ook de context uit de les erover kennen. Maar het kan wel een begin zijn, of manier om snel iets terug te zoeken.

Toelichting

In de DevOps minor leer je DevOps tools en DevOps concepten. Nu zijn tools meestal tijdelijk, zeker in een snel ontwikkelend vakgebied als DevOps. Maar (basis) concepten hebben een veel langere houdbaarheid, goede concepten zelfs oneindig...

Figuur 1 toont ludiek wat termen uit het wild, waar je ook veel buzzwords tegenkomt. Als DevOps professional moet je onderscheid kunnen maken tussen waardevolle concepten, en buzzwords.

In ieder geval is het doel wel dat deze termen ook aansluiten bij de beroepspraktijk en bestaande DevOps terminologie. De meeste woorden zijn dan ook Engels.

Hoewel de meeste feitelijk ook Nederlands zijn, of feitelijk deel uit maken van de internationale DevOps taal of jargon. Idealiter, als een concept een goede 'semantische' naam heeft, is ook voor ICT'ers de Van Dale soms een aardig begin. En zou je de originele betekenis/oorspring niet altijd terug moeten zoeken ('Death of the author' principe). Maar in de praktijk is vaak enkel de termn maar is dit niet toereikend heb je meer bronnen nodig om deze` goed te begrijpen (zie het voorbeeld uit figuur 3).

Figuur 2: Discussie thread op Twitter X over 'deployment' vs. 'release' (bron: Steve "ardalis" Smith 9-11-2023 op X)

Het plaatje in Figuur 2 toont een (vrij) recente discussie rondom checkpoints CO-302 uit het CDMM.

Concept/begrip	Uitleg
DevOps	Cultuur van samenwerken
Green field vs. brown field	Nieuwbouw project vs bestaand project en/of nieuwe/nieuwste technologie vs legacy technologie.
TODO	...
OA-001 Geconsolideerd platform & en technologie	Dit betekent dat je als organisatie een keuze hebt gemaakt qua technologie, meestal met erbij horende training, ervaring van huidige medewerkers. Bijvoorbeeld Java, of dotNet. Of Wordpress voor simpele corporate sites maar SiteCore voor complexere sites, en of multi-tenant opdrachten. Dit hoort bij lagere niveaus, omdat je bij microservices aanpak juist 'Polyglot X' kunt doen, zoals InfoSupport dat noemt, om programmeertaal of stack te laten varieren per microservice. Maar aanname is hierbij wel vaak weer een basis technologie als Kubernetes of Docker Swarm o.i.d die deze polyglot X mogelijk maken. Kortom: deze krijg je eigenlijk gratis bij gebruik PitStop, mits je gebruikte technologie maar documenteert.
BD-006 Enkele deployment scripts bestaan	Dit zijn wat handmatige deploy scripts die als basis kunnen dienen voor automatisering op de hogere levels (e.g. 'automate all the things').
BD-101 Polling builds	Ik ga uit dat dit polling model is waarbij in plaats van dat je 'git distribution' (bv. GitHub met GitHub Actions) recht geeft te pushen naar de (runtime) omgeving via opslaan credentials o.i.d., er een tool is op een andere plek die periodiek checkt (bv. elke minuut) of er in je Git repo of ander versiebeheer een nieuwere versie staat en zo ja dan die code pakt, build en containerized en evt. test. Merk op dat het testen van de build onlosmakelijk verbonden is met Continuous Integration in de definitie van Martin Fowler’s hiervan: "Each of these integrations is verified by an automated build (including test) to detect integration errors as quickly as possible."
BD-203 Build Once Deploy Anywhere	Dit 'BODE' principe houdt in dat je één keer een artefact bouwt, zoals een .jar, .war, of een Docker-image, en ditzelfde artefact gebruikt voor alle omgevingen: van test en staging tot productie.Je koppelt een specifieke commit aan het artefact en automatiseert tagging en versiebeheer, zodat je elke build uniek kunt traceren. Je beheert configuraties buiten het artefact via omgevingsvariabelen, in lijn met het 12 Factor App-principe. Door configuraties niet hard mee te bouwen, voorkom je de noodzaak om omgevingsspecifieke artefacten te maken, zoals spotitube-prod.war of spotitube-staging.war. Met één geteste en goedgekeurde build kun je direct deployen naar productie, zonder opnieuw te bouwen. Je standaardiseert het deploymentproces over alle omgevingen. Dit proces omvat ook geautomatiseerde database-migraties en gescripte runtimeconfiguratie-aanpassingen. Door deze aanpak creëer je een uniforme delivery pipeline die alle stappen omvat: van source control tot productie. Dit minimaliseert fouten, verhoogt de betrouwbaarheid en versnelt het deploymentproces. Met tools zoals ArgoCD en andere CI/CD-oplossingen automatiseer je het combineren van configuraties met de artefacten en rol je deze efficiënt uit naar meerdere omgevingen.
BD-204 Automatiseer meeste DB wijzigingen	Dit punt kun je bv. afvinken met het gebruik van de in de course fase (kort) behandelde Entity Framework (EF) Code first aanpak. Deze ondersteunt (automatische) data migraties (o.b.v. een 'single source of truth', namelijk de code). Maar alleen het gebruik van EF is voor dit punt echter niet voldoende. Je moet dan ook minstens één voorbeeld hebben van een daadwerkelijke en 'niet triviale' data migratie. Vaak hebben teams een standaard migratie voor het opzetten van de initiële database. E.g. een migratie van 'niets' naar iets. Of deze is evt. opgesplitst in een 'create' stuk en een 'insert' migratie, maar ook dat is nog triviaal (e.g. simpel). 'Niet triviaal' wil zeggen dat je de databasestructuur verandert door bijvoorbeeld een tekstveld om te zetten naar een foreign key naar een stamtabel (vaak hoort hier wijziging in de UI bij van een vrij tekstveld naar een dropdown, en/of back-end veld omzetten naar Enum i.p.v. String o.i.d.). Bij deze structuur wijziging moet je ook bestaande data migreren in je Up() én Down() methode. Of alles goed gaat moet je dan vervolgens testen, en typisch is handmatig schrijven van wat migratie code nodig. Voor afvinken moet je zo'n (voorbeeld van) een migratie ook kort toelichten in je CDMM of elders. Helemaal interessant maak je het als je een serie van wijzigingen hebt die je apart lokaal test, maar vervolgens op een test omgeving gecombineerde doorvoert (migreert) en test, liefst ook tegen kopie van productie, of gelijkwaardige set om te voorkomen dat je dit als eerste op productie doet en hierbij pas eventuele integratie problemen optreden. Let wel, dat dit is in een kleine project wel lastig te verwezenlijken. Dit vraagt ook een goede toepassing binnen het domein en afstemmen met de opdrachtgever. Als er voor de opdrachtgever geen winst in de nieuwe datastructuur zit, is de effort moeilijke te verkopen. Voor dit punt helpt het wel om heel vroegtijdig live gaan (in week 1 of 2) met een simpele datastructuur en ook bijbehorende test dataset. En hierop ook de opdrachtgever of andere testers laten werken om productie achtige gegevens in te voeren. Op deze test data kun je daarna je (niet triviale) migratie kunt doorvoeren.
BD-206 Gescripte config wijzigingen	Als je config wijzigigingen gescript hebt, kun je dit script testen op een test omgeving, en checken dat config wijzigingen doen wat je wilt, voordat je het op productie ook doet. Voorkomt fouten en zorgt voor herhaalbaarheud. Versnelt ook het proces, omdat je niet handmatig stap voor stap de config wijzigingen uit moet voeren, of op productie foutgevoelig met een editor config aanpast.
IR-402 Cross Silo analysis	Dit punt uit Information & Reporting is geavanceerd en vereist de nodige domeinkennis en overzicht van de organisatie. Dit punt is gelieerd aan Conway’s Law over de link tussen de structuur van de applicaties/microservices en de structuur van de organisatie die de applicaties gebruiken/laten bouwen. Basis eis is dat je meerdere microservices draait die Kan je systeem ook metrieken rapporteren waardoor je verbanden tussen verschillende organisatie onderdelen (silo's) kunt zien? Dat je organisatieonderdelen onderling kunt vergelijken op bepaalde aspecten? Zulke informatie geeft voor een bedrijf vaak optimalisatie mogelijkheden. Zoals InfoQ aangeeft: "Moving to expert level in this category typically includes improving the real time information service to provide dynamic self-service useful information and customized dashboards. As a result of this you can also start cross referencing and correlating reports and metrics across different organizational boundaries,. This information lets you broaden the perspective for continuous improvement and more easy verify expected business results from changes."
CO-201 Multidiscl. team (betrekken DBA, CM)	In plaats van een aparte developer team en operations team (die CM=Configuration Management) doen. En wellicht ook aparte DB admin of admins, plaats je iedereen in het team, zodat mensen vroegtijdig(er) overleggen (shift left), en wijzigingen niet tijdens deploy aan het eind vastlopen, omdat een probleem bovenkomt die iemand van andere discipline had kunnen zien aankomen. Denk bijvoorbeeld ook aan security mensen (e.g. van DevOps naar een DevSecOps team).
CO-202 Component eigenaarschap	Hoewel het hele team verantwoordelijk is voor alles, is het wel goed om een of enkele mensen eigenaar te maken van een component. Denk bij een component bijvoorbeeld aan een microservice. Dit sluit ook aan bij de 'Pizza rule' uit DevOps (NetFlix): het team verantwoordelijk voor 1 microservice moet (bij onderhoud) aan 1 pizza genoeg hebben. Dus 2 of 3 mensen?
CO-203 Handelen op metrics	Studenten vraag: > "[...] Hoe zouden wij dit moeten uitvoeren in dit project? We hebben niet echt gebruikers waarop we kunnen reageren." Antwoord: Als er geen echte gebruikers zijn, moet je deze faken. Sowieso is het een best practice om een test dataset aan te leggen in een database of andere data storage. Ook om je requirements duidelijk te krijgen, en gekozen abstracties te testen. Dit onder de noemer “Sometimes three good examples are more helpful to understand the requirements than a bad abstraction.”' - Peter Hruschka (domainstorytelling.com, 2023).
CO-206 Decentrale besluitvorming	Agile is naast cross-functional en collaberatief ook niet hiërarchisch (Wrike, z.d.). Er is dus NIET één baas, voorzitter of product owner die alles beslist. De product owner is weliswaar verantwoordelijk voor houden van overzicht van het product en WAT erin komt. Maar HOE je dit realiseert besluiten de teamleden samen, en voor decentrale besluitvorming betekent dit dat een beslissing idealiter bij de persoon die de meeste relevante kennis heeft, qua domein en/of technisch (zie ook <a href="CO-202>CO-202 Component eigenaarschap). Een probleem kan ook om 3:00 's nachts optreden, en idealiter kan er op dat moment ook een beslissing genomen worden om het op te lossen, zonder 'de baas' uit bed te bellen om een beslissing te nemen over wel/niet release van een fix en evt. release. Wel houdt CO-206 in dat je ook samen een proces opzet, waarbij je met hele team later bv. een post mortem over zo'n issue houdt, en meer structurele fix inplant, na een nachtelijke work-around/bugfix, en bv. ook je (DevOps) proces optimaliseert om kans op een soortgelijke fout later te verkleinen. Terzijde: er is ook een interessante link tussen 'decentral decision making' en het concept 'epicrocacy' zoals beschreven door Jason Brannon in zijn 'scherpe' boek 'Against democracy' (2017, voor de duidelijkheid: geen ICT boek :P).
CO-301 Dedicated Tools team	Er is een apart team in het bedrijf dedicated gericht op DevOps tools inrichten, beheren en onderzoeken. Sinds circa 2022 kwam dit principe ook onder de noemer Platform Engineering naar voren (State of DevOps, 2023). Dit houdt in dat er één apart team verantwoordelijk is voor het 'platform' waarop de IT draait. Dit lijkt op een soort interne 'Platform as a Service (PAAS)', maar sommigen spreken liever van 'Platform as a Product' (taloflow.ai, 2024, teamtopologies.com, 2021). Of pessimistisch (of realistisch?) gezegd: Het team van 'DevOps tools experts' is zo druk met hun werkzaamheden, dat ze geen tijd meer hebben voor ontwikkelwerkzaamheden in regulier teams. NB: Merk op dat het woord 'apart' een beetje indruist tegen de 'DevOps cultuur' van 'break down silo's. En een 'specialistisch' team gaat ook tegen het multi-disciplinaire karakter van DevOps teams, waarbij ook juist een Polyglot X aanpak mogelijk is. Dus dat elke deelapplicatie/microservice een andere techniek heeft (the right tool for the right job). Ook bij polyglot X is echter het (container) platform meestel wel geconsolideeerd (dat wil zeggen er zijn regels over, zodat alle teams in het bedrijf dezelfde taal en frameworks gebruiken). Dit is bijvoorbeeld Kubernetes en de de DevOps aanpak geeft veel nieuwe andere tools en technologie die aansluiten bij DevOps zoals Git, Kubernetes, Ansible, Argo. Iedereen kent de basis, maar een expertise team op dit gebied levert voor grotere bedrijven wel winst op.
CO-302 - Deployment loskoppelen van release	Hoewel ICT'ers de termen 'release' en 'deployment' vaak als synoniemen gebruiken, geeft dit CDMM checkpoint aan dat een volwassen DevOps deze 2 van elkaar los kan koppelen. Een release is een set samenhangende wijzigingen, een product increment in Scrum termen. Het 'increment' samen met het product samen leidt tot een potentially shippable product. Een nieuwe versie van je applicatie. Het 'potentially' stelt eisen aan dat de nieuwe features (voldoende) bugvrij zijn, en samenhangend. Maar het laat dus vrij of je de nieuwe versie ('release') daadwerkelijk beschikbaar stelt voor naar eindgebruikers ('productie'). Dit is dan een 'business beslissing'. Het loskoppelen heeft twee varianten. Je kan er de nieuwe release alleen deployen op een (accceptatie test omgeving, en dan beslissen er op door te itereren door nieuwe inzichten die je krijgt. Je kunt ook via bv. een 'dark release' of 'feature toggle' de onderliggende code van de functionaliteit wel degelijk opleveren, maar deze nog niet activeren (feature toggle) of bereikbaar maken (dark release). Het 'loskoppelen' gaat erom dat je dit makkelijk in kunt stellen, zodat de twee concepten 'release' en 'deployment' duidelijk van elkaar gescheiden zijn. Zie figuur 1.
OA-001 Geconsolideerd platform & technologie	Een bedrijf kiest voor een enkele technologie, of combi van bij elkaar passende technologieen (e.g. stack) voor alle applicaties. Bv. Windows (platform) en GEEN macOS. Of programmeertaal/ontwikkelomgeving .NET. Dus een medewerker kan dan niet bij een nieuwe opdracht opeens Java kiezen, ook al is er wellicht een library in Java die al 50% van de requirements vervult, die er (nog) niet voor .NET is. En een developer kan ook niet een Elixir project kiezen voor opdracht waar dit past (maar hoge concurrency eisen bv. proberen te voldoen via gebruik RabbitMQ). Of "Geen MySQL, want "we hebben een SQL Server licentie, en 3 DB admins met MS DP-300 certificaat. Dit is erg pragmatisch en komt dus veel voor, want geeft standaardisatie, maar is tegelijkertijd wel de tegenhangen van de Polyglot X aanpak die DevOps in principe mogelijk maakt (merk op dat Polyglot X zeker niet verplicht is bij DevOps).
CO-402 No rollbacks (always roll forward)	Dit checkpunt vereist wat zelfstudie, want dit punt vraagt wat verdieping en kun je over discussieren. Lees bijvoorbeeld kritische beschouwing van Jim Bird over roll forward en andere DevOps best practices of misconcepties (Bird, 2011). Dit punt moet je discussieren en toelichten als je dit punt wilt afvinken in je CDMM, met liefst beschrijving van eigen concrete situatie in je software ontwikkeltraject waar je een roll forward deed, of juist automatische rollback kon doen, en hoe dan.
OA-102 API-gestuurde aanpak	De microservices praten met elkaar met (geconsolideerde) interface, bv, RESTful API's of service bus (of RabbitM!). Dit maakt PolyGlot X aanpak mogelijk, niet alle applicaties hoeven bv., meer in Java (voorloper aanpak voor innovatie is andere taal op zelfde Virtual Machine zoals JVM (met Java, Kotlin, Scala)) of .NET met C#, F# of VB.NET voor CLR.
OA-203 Configuration as Code (CaC)	De (software) configuratie van een applicatie staat OOK in versiebeheer, zodat je het verloop hiervan over de tijd kunt zien en terugvinden (ivm auditing ook: wie heeft op 28 oktober deze setting aangepast?). Evt. kan configuratie hierbij in aparte repository staan dan code in verband met security, waar andere mensen (dan developer) verantwoordelijk voor zijn (denk aan connection strings die anders toegang tot productie db zouden geven (niet confogm AVG/GDPR)). Denk bij configuratie aan welk OS, welke software/middleware, maar ook zaken als welke software instellingen zoals IP adressen van machines). Verder kun je naast configuratie van applicatie zelf, ook denken aan configuratie van bijvoorbeeld een deployment pipeline die je applicatie build uit de code en oplevert naar een (runtime) omgeving. CaC vraagt dus de 'scripted pipelines' van Jenkins 2.0, de oude 'via UI' manier in Jenkins 1.0 geldt niet als CaC (maar wellicht kun je via UI ingestelde settings wel exporteren en dan inchecken in VCS en daarna hiermee verder werken). Hier is verder veel online over te vinden.
OA-205 Modules omzetten naar componenten	De monoliet is al wel modulair opgezet, de bestaande modules hang je in eigen microservice, bv. met eigen Docker container, zodat je ze los van elkaar kunt gaan opleveren. Heeft als potentieel probleem wel 'testing pyramid of hell'
OA-301 Volledige component gebaseerde architectuur	Next level van OA-205, met het 'strangle pattern' is een evt. oude monoliet (volgens 'monolithFirst' aanpak van Fowler) volledig omgezet in microserves
OA-302 Graph business metrics uit applicatie	Naast de standaard metrieken die bv. Grafana kan geven van cpu, geheugen en bandbreedte gebruik heb je ook custom metrics gemaakt, die ook voor de business waarde hebben. En die frequent geupdate zijn, zodat business hierop ook kan sturen, en experimenten kan doen qua business logica in de markt en zien hoe deze uitpakken (bv. A/B testen).
BD-104 1e stap naar standaardisatie deploys	Meerdere teams gebruiken zelfde stappenplan voor deploy (bv. geconsolideerde keuze is SQL Server, en men switcht van .bak bestanden naar nieuwe BacPac) en/of gebruikt Azure Cloud voor alle producten.
BD-206 Gescripte config wijzigingen	De bij BD-203 genoemde config (bv. systeemvariablen) test je ook op een test omgeving VOORdat je op productie test door een script te maken die je kunt uitvoeren. Sluit aan bij 12factor principe van one off Admin processes. Onder config wijzigingen kun je overigens naast omgevingsvariabelen ook andere config denken, zoals update van dependency bij security issue, maar bv, zelfs aanpassingen aan het database schema zien (SQL DDL scripts). In een ORM gebruik je hiervoor bv 'db migration scripts/code.
BD-401 Build bakery	Dit is een heel breed onderwerp, wat teruggaat naar de begintijd van Virtualisatie, met Amazon Machine images, maar wat feitelijk volwaasen is gemaakt door container registries en runtimes a la, waarbij je bv. een door veel applicatie hergebruikte base image hebt, met aparte config voor de specialisatie ervan (e.g. Dockerfile met CMD apk install tool-x). Vink dit punt NIET zomaar af als je Docker gebruikt, maar verdiep je in bron en argumenteer zelf waarom je hieraan voldoet.
BD-402 Zero touch continuous deployment	Geen handmatige inmenging meer nodig voor een deploy, een commit leidt automatisch tot nieuwe versie op productie, idealiter met gradual release maar dat valt hier niet bij, via de pipeline (mits linting, unit tests, automatische integratie tests etc. ). Merk op dat in projecten waar nog handmatige tests zijn dit niet altijd gewenst is, maar idealiter gebeurde dit plaats op test omgeving, en kun je via BODE principe (BD-203) risicoloos ermee naar productie via commit op main.
TV-201 Automatische component test (geisoleerd)	Geautomatiseerde integratie en/of UI test van een microservice, waarbij gebruikte dependent microservice gemockt zijn
IR-101 Meet het proces	InfoQ heeft bij het 'measure the process' stuk het voorbeeld van een aantal metrieken rondom het software ontwikkelproces zoals cycle-time of delivery time. Het proces meetbaar maken betekent dat je weet hoe lang een release duurt, dus het runnen van de pipeline. Of dat je weet hoeveel bugs er open staan op een component. En wat de gemiddelde fix tijd van een bug is. Of hoeveel bugfixes er in een release zitten. Het uberhaupt in kaart brengen is het begin van ook weten waar bottlenecks of probleemgebieden zijn in je software landschap. Waar zitten de moeilijke onderhoudbare 'big ball of mud' monolieten. Of welke modules leveren vaak bugs op. En voor de release van welke service moet je altijd een paar developers klaar hebben. Meet het proces gaat echter alleen over het inzichtelijk hebben van zulke informatie, en nog niet over het verbeteren op basis hiervan.
IR-201 Gedeeld informatie model	Dit punt is op twee manieren op te vatten. De eerste, zoals binnen InfoQ's artikel vooral bedoelt gaat het over het informatie model van het software ontwikkelingsproces zelf. Zoals je ook metrieken voor bepaakt onder IR-101. Dit informatiemodel gaat over releases, indienen van bepaalde requirements, deze formuleren als requirements en hier bijvoorbeeld unit tests of acceptatie tests voor opstellen. Ook het indelen van de software in modules of componenten (=typisch microservices), en dan de namen van deze microservices of modules. Dit is dus op meta niveau ten opzichte van het 'domeinproces' waarover de ontwikkelde applicatie gaat, en waarop ook een informatiemodel van toepassingen is. Dit gaat dan om entiteiten en hun eigenschappen zoals zichtbaar in het domeinmodel. Om aan te kunnen geven hoe het release proces verloopt, welke feature net is gereleased, of voor een komende release gepland is, of hier nog issues voor open staan, of om terug te zoeken op welke omgeving het staat, of wie dit daar gedeployed heeft, moet iedereen (of in ieder geval de juist mensen) dit terug kunnen halen uit bijvoorbeeld een code mangement systeem, een log van gedraaide pipelines, of overzicht van containers en hun versies in een container registry. Voor dit punt kun je ook denken aan het informatiemodel van de applicatie en van het domein en diens subdomeinen zelf. Denk hierbij aan DDD's ubiquitous language. Dit is een door iedereen gedeelde lijst van woorden, e.g. een 'alomvertegenwoordige taal' in een organisatie. Deze gebruiken dus zowel business mensen tijdens het werk, als developers in hun broncode (class names, foldernamen, variabele namen, methodenamen etc.). Dit houdt in dat de hele organisatie bedoelt hetzelfde met een bepaalde term. Of als één term meerdere dingen betekent in verschillende contexten, zoals bijvoorbeeld verschillende afdelingen van het bedrijf, dan zijn deze (bounded) contexts duidelijk en bekend, en is voor elke context een definitie van de term. In een microservice architectuur heeft idealiter elke microservice eigen opslag (autonomy over authority) en synchroniseer je geen informatie direct via de database (maar heb je validation layer (DDD))
IR-202 Traceerbaarheid ingebouwd in pipeline	Traceren of 'tracing' gaat over het achterhalen van fouten/bugs in software. In een DevOps omgeving denk je dan eerder aan fouten in productie (of staging), i.p.v. nog lokaal (development) waar je deze fouten kunt debuggen in je IDE. Het gaat hierbij ook vaker om integratie bugs.
IR-301 Graphing-as-a-service	Er is een aparte service die op aanvraag en redelijk gestandaardiseerd grafieken kan aanleveren. In plaats van dat elke applicatie dit intern zelf doet, en elk op eigen wijze.
IR-303 Report trend analysis	Gelieerde aan IR-402, maar in plaats van Cross Silo kan in ieder geval binnen een Silo/service/organisatie onderdeel grafieken of gegevens worden opgevraagd, maar dan wel over een bepaalde tijd, om verloop te kunnen analyseren (trend).
IR-401 Dynamische grafieken en dashboards	Spreekt hopelijk voor zich? Realtime of i.i.g. 'near realtime' data uit productie op dashboard scherm ook bereikbaar voor business mensen. Bv. het aantal openstaande issues op schermen in team work garden, maar wellicht ook direct inzichtelijk maken als/dat server geheugen volloopt, of tonen van aantal mensen momenteel in check-out scherm van webwinkel (of vergelijkbare 'custom metric' in ander/eigen domein).
OA-401 Infrastructure as Code (IaC)	Deze term is te vergelijken met Configuration as Code (CaC OA-203), alleen in plaats van de software configuratie beschrijf je nu de hardware configuratie als code. Oftewel: op welke infrastructuur gaat je software precies draaien. Dus welke CPU, hoeveel geheugen, hoeveel harde schijfruimte, maar bv. ook of bandbreedte. Voor echt hardcore IAC hoort hier ook het type hardware nog bij, zoals heb je Intel processor nodig, of AMD of een Apple M1 o.id., is je harddisk een (snelle) SSD (solid state disk) of ouderwetse magenetische schijf. Typisch gezien doe je dit bij Cloud providers, die dit soort hardware ook kunnen leveren. De precieze opties die je hebt hangen dan ook af van de Cloud provider die je gebruikt. Verschillende cloud providers hebben ook verschillende naampjes voor de machines. Er zijn ook wel speciale IaC tools/talen om meer generiek een config in te schrijven, zoals Cloudformation voor AWS (Amazon Web Services) of Azure Resource Manager (ARM, niet te verwarren met de (RISC) processor met hetzelfde acronym). Deze geven dus een soort abstractielaag om niet alle details te hoeven kennen, en minder afhankelijk te zijn van wijzigingen in hardware die er zijn. En er is zelfs cloud agnostische Terraform (hoewel de machine namen in deze config taal vaak alsnog cloud specifiek zijn). Vergeet ook niet dat je voor IaC ook tools moet hebben die deze config moeten kunnen uitvoeren (anders is het slechts een 'spec', geen code). Dit punt zit dus erg aan de OPS kant, en kun je NIET zomaar afvinken, maar moet je je echt verdiepen in IAC. Als developer wil je je vaak je software juist enigszins onafhankelijk maken van onderliggende hardware details, maar uit handen laten nemen door in te stappen op een 'X As a Service model'. Als er speciale eisen zijn, zoals gebruik GPU's i.p.v. CPU's voor bv, grafische toepassingen, of machine learning kan dit echter niet altijd meer, of als je heel grootschalig gaat werken kun je je kosten besparen als je dit zelf doet. Een goede aanzet voor dit punt, om het 'half af te vinken' kan wel zijn dat je in Kubernetes horizontal podscaling instelt ën je containers draait met zogenaamde Quality of Service instellingen hebben, dus echt vermelden van hardware karakteristieken zoals minimale CPU snelheid en harddisk ruimte.

CDMM Q&A

Q: Kunnen wij het punt CO-305 - Continuous improvement al behalen door retrospectives uit te voeren over ons individuele handelen en onze processen? A: Niet helemaal, je moet naast probleem analyse (retro), ook verbeterpunten concreet formuleren (denk Transfer uit STARRT methode) en ook doorvoeren in opvolgende sprints (of kunnen uitleggen waarom een voorgenomen improvement in de praktijk er toch niet van kwam) Q: Wat bedoelen jullie met het punt BD-207 - Standaard proces voor alle omgevingen? A: Dit gaat vooral over het deploy proces. Als antwoord een schets van een situatie waarin een team een verschillend proces per omgeving hanteert. Zonder standaardisatie verloopt het deploymentproces verschillend per omgeving:

- Op de developmentomgeving gebruiken teamleden handmatig commando’s om de app te deployen.
- Voor staging upload je bestanden via FTP.
- Production vereist speciale scripts die uniek zijn voor de live-omgeving.

 Deze verschillen leiden tot fouten, zoals configuratiemissers, vergeten updates, of inconsistente versies tussen omgevingen.

Q: Voor BD-302 - Meerdere build machines: mag mijn teamgenoot die runnen op zijn VPS? A: Ja

Q: TV-302 - Performance test? Wat moeten wij performance testen? En hoe uitgebreid? A: Performance kritieke onderdelen. Early optimisation is the root of all evil. Zei eens iemand. Maar er kwam nog wat achteraan. En performance is ook een feature, die veel geld of andere waarde (minder verspilde tijd) kan opleveren in sommige domeinen. Dus zo uitgebreid als nodig is om probleem in kaart te krijgen, maar mits het past in jullie tijdsbesteding. Stem af met opdrachtgever. Je moet echter ook wat onderzoek doen in het project, je bent met een heel team. Dus je kunt best goede tools en/of aanpakken onderzoeken. Bv. een profiler in je IDE. Of een load test tool als K6 voor webapps.

Nog over faken data: fake it till you make it

In kader van het 'shift right' is het goed om al tijdens ontwikkelen vooruit te kijken naar relevante metrics die je kunt verzamelen en waarop de business kan handelen. Dit is wel eens beschreven als een soort 13e factor als uitbreiding op de 12factor app principles. Namelijk als 'Telemetry' (namelijk in het boek van Kevin Hoffman (2016))

I like to think of pushing applications to the cloud as launching a scientific instrument into space. [...] If your creation is thousands of miles away, and you can’t physically touch it or bang it with a hammer to coerce it into behaving, what kind of telemetry would you want?

Bronnen

• Hoffman, K. 1st edition, april 2016. Beyond the twelve factor app - Exploring the DNA of Highly Scalable, Resilient Cloud Applications. Oreilly, Pivotal. Geraadpleegd op 23-10-2023 op https://www.cdta.org/sites/default/files/awards/beyond_the_12-factor_app_pivotal.pdf
• Hofer S. & Schwentner H. domainstorytelling.com (2023) Domain Storytelling: Quick-Start Guide - Feeling lost? Workplace Solutions Geraadpleegd 23 oktober 2023 op https://domainstorytelling.org/quick-start-guide#feeling-lost
• Bird, J (2011) Rolling forward and other deployment myths. DZone. Geraadpleegd laatst op https://dzone.com/articles/rolling-forward-and-other
• Smith, Steve "ardalis" (9-11-2023). Deployment vs Release. X Geraadpleegd 13 nov 2023 op https://x.com/ardalis/status/1722728350437757320
• Brannon, J. Against democracy Boekbeschrijving geraadpleegd 23 oktober 2023 op https://www.bol.com/nl/nl/p/against-democracy/9200000075205551/

Werkwijze bij DevOps weekopdrachten

Denk aan onderstaande punten bij het maken van de weekopdrachten

1. Gezamenlijk backlog/issues in GitLab, samen opstellen/verdelen
2. Kleine frequente commits (en commit op de gemaakte issues)
3. Schrijf op het eind als team samen een self assessment van jullie werk a.d.h.v. het CDMM
4. Lever in via assignen issue aan docent (+een git tag)
5. Vorm telkens duo's of grotere teams en wissel, afhankelijk van de weekopdracht

Hieronder verdere uitleg per punt.

1. Gezamenlijke backlog

Binnen Agile en DevOps is een gezamenlijke backlog ook een best practice (= "CO-101 Eén backlog per team"). Maak voor je opdracht in GitLab een planning bord aan met ook achterliggende issues aan in de reposiotory en verdeel de taken onderling (assign) op een logische manier (ieder ongeveer de helft).

Neem hiervoor samen kort opdracht door en kies korte maar logische issue titels. Gebruik issue nummer(s) ook in je commit messages, zodat je vanuit issues daarna ook door/terug kunt klikken naar gedane commits. Vergeet daarbij niet het gebruik van hekje #, bv. Fixt issue #23 domeinterm nu 'pink' ipv 'piglet'.

2. Aanhouden Git versiebeheer (best practice)

Tijdens deze course doen we versiebeheer met git. Je commit je uitwerkingen. Hanteer hierbij git (en devops) best practices, zoals:

• use small commits
• commit often
• write clear and short commit messages
• werk samen (beiden committen!)
• werk op zelfde branch of merge regelmatig

3. Self assessment

1. Schrijf SAMEN een korte reflectie en voeg toe in je README of je je aan de best practices hebt gehouden (hierboven genoemd)
2. Bekijk een aantal relevante punten uit DevOps maturity model (CDMM), Code én naam/korte beschrijving checkpunt, en geef aan of je hier aan voldoet en beoordel op welk niveau je staat in. Waarom niet, en noem verbeterpunten (bv. CO-101, CO-105, CO-205, CO-003, OA-201, OA-202, BD-103, TV-001)
3. Zijn er nog meer punten relevant? Geef waar nodig toelichting waarom jullie wel voldoen of niet, en welke punten verbetering behoeven en welke nog niet relevant waren
4. Tag de versie met git als het af is met een 'major versie' 1.0.0 en push alles. Maak een issue getiteld 'Nakijken' aan in GitLab en wijs deze toe aan de docent.

^*Tijdens het self assessment heb je wellicht de neiging nog zaken te fixen. Het netjes opdelen van commits schiet er in de praktijk vaak bij in vanwege pragmatische overwegingen. Zoals je als het goed is weet kun je in git achteraf de geschiedenis nog aanpassen. Zeker alleen lokaal; namelijk met interactive rebasing. Zie bv. 'rewriting history op de git site' de sectie 'Splitting a commit' geeft een voorbeeld.

Als je tijd hebt mag dit. Maar belangrijker dan alles goed doen, is kennis hebben hoe het voortaan goed/beter te doen (niveau 'bewust onbekwaam' ip.v. 'onbewust bekwaam'). En dit ook te kunnen formuleren voor jezelf. Dus steek je tijd liever in korte toelichting hoe je dit zou aanpakken, of precies waarom het niet lukt (wat is de reden, wat is de foutmelding die je kreeg? welke stappen heb je gezet?).

Let op: een self assessment betekent NIET een individuele assessment. Het is wel okee (zelfs goed) eerst onafhankelijk van elkaar een assessment te bedenken, maar overleg je mening en voeg daarna de punten uit beiden samen en overleg om tot een teamoordeel te komen.

Schrap daarbij ook onnodig lange, dubbele of achteraf onjuiste of onduidelijke zaken (samenvoegen is namelijk iets anders dan achter elkaar plakken). Dit is ook een vorm van integratie (e.g. bij 'Continuous Integration denk je waarschijnlijk primair aan integreren van code e.g. pull requests, maar ook documentatie hoort hierbij, en een self assessment is ook een vorm van documentatie).

4. Inleveren

Als je klaar bent maak dan een issue aan in/bij je GitLab repo met titel Nakijken en assign deze aan je docent.

De docent beoordeelt je werk in gitlab en of het voldoende is. Zo niet dan maakt de docent een issue aan om te fixen met korte beschrijving. Volgens de Joel test geldt in principe 'fix bugs before you write new code'. Je moet in principe een voldoende hebben voordat je naar volgende opdracht.

NB Aan het eind van van de course upload je een .zip met al je opdrachten naar iSAS voor het archief (namelijk voor evt. accreditatie checks bij AIM). Dit inleveren is een eis om totaalbeoordeling/-cijfer te krijgen (want na cijfer toekenning door docent gaat je inlevermogelijkheid automatisch dicht).

Wat moet ik waar uploaden in iSAS?

Hier het totaal overzicht van wat waar in te leveren in iSAS (2024):

• MINDEC03
  • TOETS-02 - Beroepsproduct Dev <-- Onderzoeksblog repo + presentatie slides?
  • TOETS-03 - Huiswerkopdrachten Dev <-- Linux Bash script & RabbitMQ groepsrepo
• MINDEC04
  • TOETS-02 - Beroepsproduct DevOps <-- PitStop uitbreiding BP groepsrepo
  • TOETS-03 - Wekelijkse Huiswerkopdrachten DevOps <-- Verzamelzip weekopdracht 1, 2, 3 en 5

5. Groepsvorming voor wekelijkse Opdrachten

Om het samenwerken te oefenen, heb je voor elke opdracht wisselende teamgrootte en -partners. Als developer heb je wellicht de neiging om alles in je eentje te doen, want dat scheelt een boel overhead. En een klasgenoot vragen/vinden kan best spannend zijn. DevOps gaat echter over samenwerken. Voor het managen hiervan heb je ook de tools maar geldt uiteindelijk:

'Individuals and interactions over processes and tools' - Agile manifesto

Week 1

• Vorming van Paren:
  • Studenten vormen zelfgekozen paren.
  • Taalvereiste:
    • 50% van de paren moet werken in Java.
    • De andere 50% werkt in C#.

Week 2

• Wisselen van Partner:
  • Studenten moeten van partner wisselen.
  • Taalkeuze:
    • Elk paar kan kiezen tussen Java of C# op basis van de behoeften van hun project.

Week 3, 4 en 5

• Flexibele Paren:
  • Paren kunnen opnieuw wisselen.
  • Terugkeren naar het oorspronkelijke paar is toegestaan.

Beschrijving Onderwijseenheid (OWE)

• 1. Inleiding
  • Links naar iSAS
• 2. DevOps competenties
• 3. Dev competenties (DevOps4Dev)
• 4. Ops competenties (DevOps4Ops)
• 5. DevOps - Project competenties
  • 6.5.1 Project-1-1 Vormbehoud
  • 6.5.2 Project-1-1 T-shaped
  • 6.5.3 Project-1-1 Onderzoek
  • 6.5.4 Project-1-1 Ontwerpdocumentatie
  • 6.5.4 Project-1-1 Agile
  • 6.5.5 Communiceren en reflecteren
• 6. Beoordelingscriteria per competentie
  • 6.1 Toelichting sectienummers en nummering competenties en beoordelingscriteria
  • 6.2 DevOps beoordelingscriteria per competentie
    • 6.2.1 DevOps-1 Continuous Delivery (Cultuur & Organisatie)
    • 6.2.2 DevOps-2 GitOps (Build & Deploy)
    • 6.2.3 DevOps-3 Containerization (Design & Architectuur)
    • 6.2.4 DevOps-4 DevSecOps (Test & Verificatie)
    • 6.2.5 DevOps-5 SlackOps (Information & Reporting)
    • 6.2.6 DevOps-6 Onderzoek
    • 6.2.7 DevOps-7 Attitude
  • 6.3 Dev beoordelingscriteria per competentie
    • 6.3.1 Dev-1 Linux
    • 6.3.2 Dev-2 Protocollen
    • 6.3.3 Dev-3 Behaviour Driven Development
    • 6.3.4 Dev-4 Design en Domain Driven Design
    • 6.3.5 Dev-5 Onderzoek
  • 6.4 Ops beoordelingscriteria per competentie
    • 6.4.1 Ops-1 DevSecOps
    • 6.4.2 Ops-2 Chaos monkey
    • 6.4.3 Ops-3 Quality Attributes
    • 6.4.4 Ops-4 Infrastructure As Code
    • 6.4.5 Ops-5 Onderzoek
• 7. Mapping tussen toetsen en course- en projectcompetenties
  • 7.1 Toetsing Course DevOps (10 ECTS)
  • 7.2 Toetsing Course Ops (5 ECTS)
  • 7.3 Toetsing Course Dev (5 ECTS)
  • 7.4 Toetsing DevOps Project (15 ECTS)
    • 7.4.2 Toelichting afwijken reguliere AIM projectbeoordeling
• 8. Onderwijsmaterialen
• 8. Ingangseisen
  • 9.2 Vereiste voorkennis Developers
• Bronnen

1. Inleiding

Deze OWE beschrijving (onderwijskundige eenheid) geeft voor de 'Minor DevOps' (MDO) de competenties, beoordelingscriteria en wijze van toetsing van alle courses en het project. Dit is een AIM norm; de OWE komt ook in het Onderwijs Statuut (OS/OER document). Een meer algemene introductie op deze minor staat op de home pagina van deze website.

De OWE is opgedeeld in secties. Deze hebben naast titel ook een nummer voor het overzicht. De eerste secties hebben geen subsecties omdat ze vrij kort zijn, maar verderop zijn er subsecties met subnummer.

Na deze inleiding volgen in sectie 2, 3 en 4 eerst de competenties van elk van de 3 courses in blok 2. In sectie 5 staan de competenties van het eropvolgende project in blok 2. In sectie 6 komen in subsecties de beoordelingscriteria bij elk van de competenties horen. Deze geven meer details. In sectie 7 volgt tot slot een overzicht van verschillende toetsen voor elk van de courses en toetsvormen en wegingsfactoren en dergelijke. Deze sectie geeft ook de mapping van de competenties en beoordelingscriteria naar de toetsen die deze.... toetsen en beoordelen :).

Tot slot in sectie 8 nog high level de onderwijsmaterialen en in sectie 9 een lijst van vereiste voorkennis voor toegang tot de minor (momenteel alleen ISM en developer profielen van HAN - AIM, in de toekomst wellicht breder toegankelijk voor HBO ICT studenten).

Links naar iSAS

De publiek zichtbare variant van de OWE beschrijvingen is iSAS, hier de links:

• DevOps
• Dev
• Project

2. DevOps competenties

In de 'DevOps' middencourse ontwikkelen alle studenten van de minor als het goed onderstaande competenties. Merk op dat achter elke competentie een kort woord of woord combinatie tussen haakjes staat. Hoewel hiermee niet de gehele zin (e.g. competentie beschrijving) gevat wordt in enkel dit woord, geeft dit wel kernachtig een kernbegrip weer van de competentie. Dit dient als ezelsbrug, ook wel 'mnemonic' genoemd (een concept uit assembly talen). Bij een aantal competenties is dit het DevOps 'buzzword'/thema van de verschillende geplande onderwijsweken (zoals 'Continous Delivery' of 'gitops'). Let wel deze mapping op de ezelsbruggetjes is wel enigszins grof. Zo komt de pipeline die centraal staat bij Continuous Delivery bijvoorbeeld in meerdere weken terug, met aspecten als toepassen van unit tests, automatische deploy etc. verdeeld/verspreid over meerdere lessen/weken.

• DevOps-1 Je kunt goed samenwerken in een DevOps team en draagt bij aan het iteratief opleveren van nieuwe 'Cloud producten' (Continuous Delivery)
• DevOps-2 Je kunt werken met versiebeheer centraal in de DevOps aanpak en kent en gebruikt bijbehorende workflows en CI/CD systemen (GitOps)
• DevOps-3 Je kunt werken met containers, gangbare software architecuren vertalen naar een container architectuur en de principes van container orchestration toepassen (Containerization)
• DevOps-4 Je kent de rol van testen, TDD en andere testaanpakken, kent DevOps security best practices, kan deze opvolgen en package managers gebruiken (DevSecOps)
• DevOps-5 Je kunt goede logging en monitoring realiseren in verschillende omgevingen en zorgen voor applicatiespecifieke rapportages (SlackOps)
• DevOps-6 Je kunt onderzoeksmethoden gebruiken en resultaten uit zelf verricht onderzoek, en dat van anderen toepassen in een beroepsproduct (Onderzoek)
• DevOps-7 Je laat een nieuwsgierige instelling zien gecombineerde met een pragmatische aanpak en een positief kritische houding (Attitude)

3. Dev competenties (DevOps4Dev)

In de 'DevOps4Dev' schakelcourse leren de instromende 'developer' studenten onderstaande kennis en vaardigheden (e.g. competenties). Merk op dat voor het gemak de competenties codes de vorm 'Dev-x' hebben in plaats van het meer verbose 'DevOps4Dev-x'. Maar dit laatste zou wel correcter zijn.

• Dev-1 Je kent de rol en functie van besturingssystemen en kent de basis van Linux server beheer en administratie (Linux)
• Dev-2 Je kent voor DevOps relevante protocollen, netwerkstandaarden en security principes (Protocollen)
• Dev-3 Je kunt kwalitatieve unit tests en automated acceptance tests schrijven en reviewen en ontwikkelen volgens Behaviour Driven Development (BDD)
• Dev-4 Je kent een aantal basisprincipes van software design in het algemeen en Domain Driven Design in het bijzonder ((DD) Design)
• Dev-5 Je kunt zelfstandig verdiepend onderzoek verrichten en de uitkomsten op een voor vakgenoten heldere manier verwoorden (Onderzoek)

4. Ops competenties (DevOps4Ops)

In de 'DevOps4Ops' schakelcourse doen de instromende 'operations' studenten onderstaande kennis en kunde op (e.g. competenties). Merk op dat analoog aan DevOps4Dev de competenties codes weer simpele vorm 'Ops-x' hebben in plaats van 'DevOps4Ops-x', hoewel dit laatste wellicht correcter zou zijn.

• Ops-1 Je ontwerpt en ontwikkelt een DevOps-pipeline, zodat je beveiligingsrisico’s zo vroeg en effectief mogelijk kan signaleren en beheersen (DevSecOps)
• Ops-2 Je valideert een DevOps-pipeline ten aanzien van prestatie-efficiëntie en betrouwbaarheid met methoden zoals performance testing, chaos engineering en monitoring. (Chaos engineering)
• Ops-3 Je ontwerpt DevOps-structuren (zoals multi-project pipelines) ook op het hoogste abstractieniveau (architectuur), om zo de kwaliteit van softwarediensten in productie te optimaliseren. (quality)
• Ops-4 Je ontwerpt en ontwikkelt volgens het ‘infrastructure as code’-paradigma. Je analyseert voor- en nadelen voor de opdrachtgever van het ‘infrastructure as code’-paradigma vergeleken met alternatieve paradigma’s zoals interactieve configuratie en geautomatiseerde configuration management.
• Ops-5 Je kunt zelfstandig verdiepend onderzoek verrichten en van de uitkomsten op een heldere verslag doen zodat vakgenoten dit snel kunnen begrijpen (Onderzoek)

5. DevOps - Project competenties

N.B.: Richting 2023/2024 'multidisciplinair project' aangepast naar 'DevOps groepsproject met een authentieke opdrachtgever'

• Project-1 Kan in de courses opgedane kennis en vaardigheden toepassen in een DevOps groepsproject met een authentieke opdrachtgever. #Vormbehoud
• Project-2 Kan onderscheid maken tussen groepsbelangen en belangen inzake de eigen discipline. #Tshaped
• Project-3 Gebruikt analyse- en onderzoeksmethodieken, -technieken en -gereedschappen en trekt gedegen conclusies uit bevindingen. #onderzoek
• Project-4 Kan, gegeven een probleem, een beargumenteerde keuze maken over ontwerpbeslissingen. #Ontwerpdocumentatie
• Project-5 Werkt methodisch en Agile bij het realiseren en/of inrichten van een gekozen oplossing. #Agile
• Project-6 Communiceert helder over de resultaten van zijn/haar werk, toont aan onverwachte situaties te kunnen oplossen en kan reflecteren op en lering te trekken uit het multidisciplinaire project. #CommunicerenReflecteren

Bovenstaande wordt per minor per september 2024 gewijzigd naar:

• MDO-Project-1 Kan de 'DevOps volwassenheid' van een gemaakt product en DevOps team aangeven aan de hand van een aangereikt DevOps maturity model #SelfAssessment
• MDO-Project-2 Kan een door opdrachtgever aangereikte ontwikkelstack gebruiken en gebruik van extra technologieën goed afstemmen, beargumenteren en documenteren #DevOpsTechnology
• MDO-Project-3 Kan Agile werken, een rol in een team invullen en ceremonies gebruiken om tot een steeds beter product en proces te komen #WayOfWorking
• MDO-Project-4 Kan een staging én productie omgeving inrichten met bijbehorende pipelines, toenemende productkwaliteit en frequentie van opleveringen #BuildAndDeployment
• MDO-Project-5 Kan een DevOps product documenteren met README's, software architectuur diagrammen met toelichting en een verzameling van gemaakte architectuur beslissingen #Documentatie
• MDO-Project-6 Toont een professionele werkhouding door proactieve communicatie met opdrachtgever en begeleiders, een goede en onderling kritische werksfeer in het team en het maken van en zich houden aan afspraken #SoftSkills
• MDO-Project-7 Heeft een nieuwsgierige houding, zet in courses opgedane kennis en vaardigheden pragmatisch in en bekwaamt zichzelf verder via onderzoek en kritische zelfreflectie #attitude

6.5.1 Project-1-1 Vormbehoud

• Self assessment (CDMM checkpoints met toelichtingen + cijfer indicatie 5 hoofdcategorieën)
• c. Build en Deployment (ontwikkelstraat, Azure DevOps, etc.)
• Verantwoording eigen bijdrage: CI/CD pipelines, ontwikkelstraat, app configuratie, containerization, versiebeheer, monitoring, security, documentatie

6.5.2 Project-1-1 T-shaped

• a. Technologie (techstack, devops tools, monitoring/metrics)
• Verantwoording eigen bijdrage: broncode

6.5.3 Project-1-1 Onderzoek

• Verantwoording eigen bijdrage: Onderzoek

6.5.4 Project-1-1 Ontwerpdocumentatie

• d. Documentatie (C4, continuous documentation, ADR's, etc.)
• Verantwoording eigen bijdrage: documentatie

6.5.4 Project-1-1 Agile

• b. Way of Working (Scrum, Storymap, etc.)
• Verantwoording eigen bijdrage: review, Agile werkproces

6.5.5 Communiceren en reflecteren

• e. Soft Skills (effectief Agile werken, communiceren en presenteren aan technische+niet technische stakeholders)
• Verantwoording eigen bijdrage: groepsproces, communicatie opdrachtgever en soft skills, leerervaringen en conclusies

6. Beoordelingscriteria per competentie

De subsecties 6.2 tot en met 6.5 geven voor elk van de competenties van elk van de 3 courses en het project de beoordelingscriteria die de competentie verduidelijken en beoordeeling concreter maken. Vanwege het DRY principe (Don't Repeat Yourself) zijn de competenties hierbij NIET herhaald. In 6.1 eerst een korte toelichting over nummering.

6.1 Toelichting sectienummers en nummering competenties en beoordelingscriteria

De nummering van subsubsecties met beoordelingscriteria hieronder komt overeen met de nummering van hoofdsecties met de bijbehorende competentie. Dus beoordelingscriteria in sectie 6.x.y horen bij de competentie in sectie x (bv. 6.3.x horen bij sectie 3). Dit is — mede — dankzij het invoegen van deze inleidende sectie 6.1 met een structuurbeschrijving. Dit is een soort interne 'leeswijzer'. Zonder dat het als een kopje 'leeswijzer' heeft, maar een meer inhoudelijke naam. Tip: Volg dit voorbeeld in het blog van je onderzoek (een toets)! Gebruik ook sectienummers en subsectienummers zoals hier om kortere interne verwijzing te (kunnen) doen. Gebruik NIET meer niveaus dan 3 (subsubsecties is diepste niveau, in analogie met Linus (Torvalds, z.d.) richtlijn in de Linux kernel coding style: "...if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

Om de koppeling met de competentie duidelijk te maken hebben de beoordelingscriteria een subcijfer. Voor competentie DevOps-7 zijn bijvoorbeeld 3 beoordelingscriteria met code DevOps-7-1, DevOps-7-2 en DevOps-7-3.

NB Net als bij de competenties zegt de gebruikte volgorde van beoordelingscriteria niet per se iets over de volgorde van onderwerpen in de lessen.

6.2 DevOps beoordelingscriteria per competentie

De 5 competenties van de algemene 'middencourse' DevOps beschreven in sectie 2 mappen naar respectievelijke beoordelingscriteria opgesomd in de nu volgende sectie 6.2.1 tot en met 6.2.7.

6.2.1 DevOps-1 Continuous Delivery (Cultuur & Organisatie)

• DevOps-1-1 Kent de Agile principes en kan uitleggen hoe DevOps in het verlengde hiervan ligt
• DevOps-1-2 Vindt een eigen rol in een team, neemt hierbinnen verantwoordelijkheid en communiceert proactief binnen het team en naar buiten
• DevOps-1-3 Kan helder, ondubbelzinnig en doelgroepgericht communiceren over Devops concepten, practices en producten zowel mondeling als schriftelijk
• DevOps-1-4 Levert een DevOps product op iteratieve wijze op, en kan je bijdrage hieraan zelf onderbouwen
• DevOps-1-5 Kent en gebruikt correct voor DevOps relevante concepten zoals MVP, product-increment, greenfield, brownfield en microservices
• DevOps-1-6 Kent de grote cloud providers/platforms, de verschillende '... as a service' categorieen en het onderscheid tussen public en private cloud

6.2.2 DevOps-2 GitOps (Build & Deploy)

• DevOps-2-1 Kan een CI/CD pipeline opzetten en configureren voor handmatige en automatische deployment naar meerdere omgevingen (OTAP)
• DevOps-2-2 Kent de centrale rol van een versiebeheersysteem in DevOps en belangrijke GitOps concepten zoals push- vs pull model, reconcilliation en desired state
• DevOps-2-3 Kan goed omgaan met een versiebeheersysteem (Git) en kent de principes hierachter en enkele advanced features ervan
• DevOps-2-4 Kent enkele workflows voor teams in een VCS platform, methodes van 'trunk based development' en realiseert hiermee Continous Integration
• DevOps-2-5 Kent Continuous Deployment strategieen zoals green-blue deployment, feature toggles en canary deploys en past één of meer toe

6.2.3 DevOps-3 Containerization (Design & Architectuur)

• DevOps-3-1 Kent basisprincipes van testen, de testpiramide en kan geautomatiseerde tests uitvoeren en code coverage bepalen met een tool
• DevOps-3-2 Kent best practices en principes voor Cloud applicaties en kan deze verifieren (12factor principes)
• DevOps-3-3 Kan applicatie onderdelen 'containerizen' en onderling laten communiceren
• DevOps 3-4 Kent de rol van netwerken bij containers, en principes van een load balancer, firewall en proxy en relevante protocollen/standaarden
• DevOps 3-5 Kent de principes van een message broker en past er een toe in een multi-container applicatie
• DevOps 3-6 Kent de basisprincipes van InfraStructure as Code en hoe dit past binnen de DevOps aanpak
• DevOps 3-7 Kent de basisprincipes van Domain Driven Design en kan deze toepassen en toetsen in DevOps code, configuratie en documentatie

6.2.4 DevOps-4 DevSecOps (Test & Verificatie)

• DevOps-4-1 Is security aware tijdens het realiseren van een DevOps product en houdt overzicht van zwakke plekken
• DevOps-4-2 Kan containers scannen en vulnerabilities en security alerts opvolgen via updates m.b.v. een package manager
• DevOps-4-3 Kent een aantal DevOps security best practices en past deze toe
• DevOps-4-4 Weet wat CVE's zijn en de relatie leggen naar eigen code/product en gebruikte depdencies
• DevOps-4-5 Kan evt. regressiefouten als gevolg van security update opsporen en uitsluiten in productie

6.2.5 DevOps-5 SlackOps (Information & Reporting)

• DevOps-5-1 Kent best practices voor logging in een containerized omgeving en kent de integratiepunten van tools als Docker en Kubernetes
• DevOps-5-2 Kan hardware gebruik in een container cluster monitoren en rapporteren en ook applicatiespecifieke monitoring toevoegen
• DevOps-5-3 Kan directe rapportage in- en integratie met collaboratietools als bijvoorbeeld MS Teams, Slack of Discord realiseren

6.2.6 DevOps-6 Onderzoek

• DevOps-6-1 Kan zich snel verdiepen in nieuwe DevOps technologieen in het verlengde van bestaande kennis en kunde en kan inschatten of verder onderzoek een goede tijdsinvestering is
• DevOps-6-2 Kent onderzoeksmethoden voor praktijkgericht onderzoek en past deze toe in de realisatie van het beroesproduct
• DevOps-6-3 Maakt gebruik van onderzoeksresultaten van anderen en jezelf, verantwoordt de kwaliteit van het onderzoek en geeft een correcte bronvermelding

6.2.7 DevOps-7 Attitude

• DevOps-7-1 Bent pragmatisch, stelt zelf vantevoren een voldoende duidelijk einddoel en werkt hier naartoe, maar kunt je werk ook timeboxen en inschatten wanneer 'You ain't gonna need it'
• DevOps-7-2 Bent positief kritisch op gebruikte bronnen, gemaakte specificaties, ontwerpen, producten en rapportages van jezelf en anderen
• DevOps-7-3 Toont een kritische blik in verslaglegging, documenteert known issues en 'speelt op de bal; niet op de persoon'
• TODO: DevOps-7-4 Werkt goed samen en fungeert als T-shaped professional zoekend naar verdieping in een of enkele onderwerpen, maar ook breed georienteerd op andere onderwerpen en overdracht van en naar teamgenoten

6.3 Dev beoordelingscriteria per competentie

Hieronder alle beoordelingscriteria voor de competenties van developers specifieke course beschreven in sectie 3.

6.3.1 Dev-1 Linux

• Dev-1-1 Kan met behulp van command line/terminal navigeren op eigen systeem en externe Linux servers en systeeminformatie opvragen
• Dev-1-2 Je kan containers debuggen via gebruik van standaard linux tools gebruiken en nieuwe tools installeren
• Dev-1-3 Je kent de rol van Linux voor containers, en hoe containers op andere operating systemen draaien

6.3.2 Dev-2 Protocollen

• Dev-2-1 Kan een load balancer instellen en configureren voor een container of container cluster
• Dev-2-2 Kent het gebruik van het DNS protocol in containers en past deze toe voor container communicatie
• Dev-2-3 Kan netwerk instellen en communicatie tussen verschillende netwerken mogelijk maken
• Dev-2-4 Kent verdere voor DevOps relevante protocollen, implementaties hiervan en architecturele stijlen zoals RabbitMQ, etcd en REST

6.3.3 Dev-3 Behaviour Driven Development

• Dev-3-1 Kent de BDD principes en tools en kan samen met eindgebruikers en/of niet ontwikkelaars requirements opstellen en uitwerken
• Dev-3-2 Kent de relatie tussen TDD en BDD en kan de toegevoegde waarde van elk uitleggen
• Dev-3-3 Kan hoge test coverage realiseren en aantonen en kent de waarde en beperkingen hiervan
• Dev-3-4 Kent de principes van de test pyramide en past deze effectief toe in een DevOps omgeving

TODO: Evt. aanpassen, omdat we Dev-3 in 2021 in de DevOps course behandelden.

6.3.4 Dev-4 Design en Domain Driven Design

• Dev-4-1 Kent de belangrijkste strategic patterns uit Domain Driven Design namelijk Ubiquitous Language, Bounded Context en Context mapping en past deze toe
• Dev-4-2 Kent enkele tactical patterns uit DDD, namelijk Services, Entities, Value Object en het Aggregate pattern, en past deze toe indien mogelijk
• Dev-4-3 Kan een software architectuur ontwerp documenteren met diagrammen en een duidelijke toelichting hierop geven met extra informatie en aandachtspunten

TODO: Evt. aanpassen, omdat we Dev-4-1 en Dev-4-2 in 2021 in de DevOps course behandelden, namelijk de InfoSupport workshops. Hier was ook aandacht voor Event Driven Architectures zoals CQRS.

6.3.5 Dev-5 Onderzoek

• Dev-5-1 Verdiept zich zelfstandig in Devops concepten en nieuwe DevOps technologieen (tools, talen, frameworks of practices, principles, patterns)
• Dev-5-2 Beschrijft onderzoeksresultaten helder, ondubbelzinnig, gestructureerd en doelgroepgericht
• Dev-5-3 Selecteert bruikbare bronnen van derden en doet correcte bronvermelding

Merk op dat de de competentie en beoordelingscriteria voor Dev-5 en Ops-5 'onderzoek' identiek zijn.

6.4 Ops beoordelingscriteria per competentie

De competenties specifiek voor operations en infrastructuur en security studenten mappen elk ook naar een aantal beoordelingscritera in de volgende 5 subsecties.

6.4.1 Ops-1 DevSecOps

• Ops-1-1 Je kunt security problemen oplossen via een update zonder een voor eindgebruikers merkbare verstoring
• Ops-1-2 Je kan relevante security issues uit OS of middleware vinden met een tool of via handmatig doornemen van security rapporten
• Ops-1-3 Je kan een update doorvoeren in een test omgeving en daar via (bestaande) tests bepalen of er regressie issues zijn
• Ops-1-4 Je kent een techniek voor incremental rollout van de nieuwe applicatie versie en kan problemen hierbij monitoren
• Ops-1-5 Je bent je bewust van mogelijkheden en onmogelijkheden bij oplossen van security issues en hoe hierover te communiceren met stakeholders en developers

6.4.2 Ops-2 Chaos monkey

• Ops-2-1 Je kent de principes van chaos engineering en toegevoegde waarde hiervan
• Ops-2-2 Je kunt een tool gebruiken om chaos engineering toe te passen in een containerized omgeving
• Ops-2-3 Je weet hoe productie en QA/test omgeving zo te configureren dat chaos engineering effectief is

TODO '22: Competentie(s) rondom chaos engineering verplaatsen naar DevOps course, in ieder geval de conceptuele (e.g. Ops-2-1)

6.4.3 Ops-3 Quality Attributes

• Ops-3-1 Je kunt de rol van System Quality Attributes in een software ontwerp beschrijven en voldoen aan deze requirements inzichtelijk maken met een DevOps aanpak
• Ops-3-2 Je kunt met een orchestration tool als Kubernetes configuratie opzetten voor bijvoorbeeld autoscaling, Quality of Service en health checks
• Ops-3-3 Je neemt verantwoordelijkheid voor non-functionele eisen van een applicatie en weet hoe deze te monitoren en verbeteren ook rekening houdend met kosten aspecten

6.4.4 Ops-4 Infrastructure As Code

• Ops-4-1 Je kent de principes van IAC en kunt deze toepassen met behulp van een tool in een private of public cloud
• Ops-4-2 Je kunt een nieuwe test of productie omgeving inrichten, uitrollen en documenteren voor gebruik door teamleden die weinig van IAC afweten
• Ops-4-3 Je kunt in een bestaande applicatie InfraStructure As Code introduceren of stapsgewijs toewerken naar een meer 'cattle not pets' aanpak

6.4.5 Ops-5 Onderzoek

• Ops-5-1 Je verdiept je zelfstandig in Devops concepten en nieuwe DevOps technologieen (tools, talen, frameworks of practices, principles, patterns)
• Ops-5-2 Je beschrijft onderzoeksresultaten helder, ondubbelzinnig, gestructureerd en doelgroepgericht
• Ops-5-3 Je selecteert bruikbare bronnen van derden en doet correcte bronvermelding

Merk op dat de de competentie en beoordelingscriteria voor Dev-5 en Ops-5 'onderzoek' hetzelfde zijn.

7. Mapping tussen toetsen en course- en projectcompetenties

Hieronder voor elk van de 3 courses en het project de beoordelingscriteria die deze specifiek toetsen. Ook andere gegevens als toetsvorm en deelcijfers.

Het verschil tussen beoordelingscriteria en deelcijfers is dat criteria vakinhoudelijk zijn, terwijl deelcijfers meer over de vorm of fasering gaan. Zo kennen de courses wekelijkse deeltoetsen die docenten of student assistenen afzonderlijk beoordelen, maar wiens gemiddelde cijfer een enkele toets vormt.

De deelopdrachten die je per week opbouwt commit je naar de je persoonlijke remote git repository (voor de week deadline!) zodat deze voor beoordelaar inzichtelijk zijn. Maar i.v.m. AIM standaarden en externe accreditatie moet je een verzamel .zip uit git van alle opdrachten op het eind van de course (en voor de deadline die in iSAS staat) ook uploaden in iSAS voordat je een cijfer kunt krijgen. Geen upload is geen beoordeling.

7.1 Toetsing Course DevOps (10 ECTS)

• BP_Team Teamcijfer beroepsproduct
  • Toetsvorm: Beroepsproduct
  • Toetsvorm extra: DevOps product, inclusief team demo documentatie en individuele verantwoording schriftelijke en mondeling
  • Gewicht, grens: 60%, >= 5,5
  • Deelcijfers:
    • Kwaliteit en kwantiteit 'DevOps beroepsproduct' inclusief documentatie (aka 'product')
    • Duidelijkheid van Team demo van product en WIJ`E beantwoorden vragen
    • README + Documentatie
    • Team product review + self assessment
    • Kwaliteit en kwantiteit individuele werk
    • Duidelijkheid en aantrekkelijkheid toelichting/verantwoording individuele bijdrage
    • Toepassen onderzoek in BP met bronvermelding
    • Reflectie eigen functioneren mondelinge toelichting
• Leeruitkomsten (percentage toetsmatrijs tussen haakjes):

  • DevOps-1 Continuous Delivery (15%)

  • DevOps-2 Containerization (14%)

  • DevOps-3 GitOps (14%)

  • DevOps-4 DevSecOps (14%)

  • DevOps-5 SlackOps (14%)

  • DevOps-6 Onderzoek (14%)

  • DevOps-7 Attitude (15%)

  • T_DevOps 2-wekelijkse theorietoetsen

    • Gewicht, grens: 40%, >= 5.5
    • Deelcijfers:
      • week 3, >= 4.0
      • week 6, >= 4.0
    • Leeruitkomsten (percentage toetsmatrijs tussen haakjes):
      • DevOps-1 Kent Continuous Delivery principes, concepten en tools (20%)
      • DevOps-2 Kent Containerization principes, concepten en tools (20%)
      • DevOps-3 Kent GitOps principes, concepten en tools (20%)
      • DevOps-4 Kent Orchestration en DevSecOps principes, concepten en tools (20%)
      • DevOps-5 Kent SlackOps principes, concepten en tools (20%)

  • Opdr_DevOps Wekelijkse huiswerkopdrachten DevOps

    • Toetsvorm Extra: Github commits + iSAS .zip
    • Gewicht, grens: Vink
    • Deelcijfers:
      • 5 weekopdrachten, allen vink, of gemiddeld voldoende
    • Leeruitkomsten (percentage toetsmatrijs tussen haakjes):
      • DevOps-1: Kan Continuous Delivery toepassen (20%)
      • DevOps-2: Kan Containerization toepassen (20%)
      • DevOps-3: Kan GitOps toepassen (20%)
      • DevOps-4: Kan Orchestration en DevSecOps toepassen (20%)
      • DevOps-5: Kan SlackOps toepassen (20%)

7.2 Toetsing Course Ops (5 ECTS)

• T_Ops Gemiddelde van theorie(deel)toetsen Ops

  • Toetsvorm: 2 theorietoetsen digitaal
  • Gewicht, grens: 50%, >= 5.5
  • Beoordelingscriteria:
    • Ops-1 'DevSecOps: Alle beoordelingscriteria
    • Ops-2 'Chaos Engineering': Alle beoordelingscriteria)
    • Ops-3 'Quality Attributes': Alle beoordelingscriteria
    • Ops-4 'Infrastructure as Code': Alle beoordelingscriteria

• Blog_Ops Blog n.a.v. onderzoek

  • Ops-5 (onderzoek)

• Opdr_Ops Wekelijkse huiswerkopdracht Ops

  • Toetsvorm Extra: Github commits + iSAS .zip
  • Gewicht, grens: 50%, >= 5.5
  • Deelcijfers:
    • Week 2: Vink
    • Week 4: Vink
  • Leeruitkomsten (percentage toets matrijs tussen haakjes):
    • Ops-1: Kan DevSecOps toepassen (todo)
    • Ops-2: Kan Quality Attributes opstellen, realiseren en toetsen (todo)
    • Ops-3: Kan Chaos Engineering toepassen (todo)
    • Ops-4: Kan kan Infrastructure as Code toepassen (todo)

7.3 Toetsing Course Dev (5 ECTS)

• T_Dev Gemiddelde van theorie(deel)toetsen Dev
  • Toetsvorm: Wekelijkse deeltoetsen
  • Gewicht, grens: 50%, >= 5.5
  • Leeruitkomsten (percentage toetsmatrijs tussen haakjes):
    • Dev-1 Linux: Alle beoordelingscriteria (50%)
    • Dev-2 Protocollen: Alle beoordelingscriteria (25%)
    • Dev-3 BDD: Alle beoordelingscriteria (0%)
    • Dev-4 (DD) Design/C4/Continuous Documentation: Alle beoordelingscriteria (25%)

TODO okt '21: Stof Dev-2+Dev-3 en Dev-4 behandelt tijdens DevOps les respectievelijk InfoSupport workshops en getoetst in DevOps deeltoets 2 (m.u.v. Dev-4-3 arch/doc. met C4 en Continuous Documentation en In Dev-2 moet RabbitMQ beter verwerkt in volgende editie) TODO sept '23: Stof micro front-ends moet nog een leeruitkomst bij, of verwerken in/herformuleren van Dev-4

• Blog_Dev Blog n.a.v. onderzoek

  • Toetsvorm: Markdown commits + pdf iSAS
  • Gewicht, grens: 50%, >= 5.5
  • Beoordelingscriteria:
    • Dev-5 'Onderzoek': Alle beoordelingscriteria (100%)

• Opdr_Dev

  • Toetsnaam: Wekelijkse huiswerkopdracht Dev
  • Gewicht, grens: Vink
  • Toetsvorm Extra: Github commits + iSAS .zip
  • Deelcijfers:
    • Week 2: Vink
    • Week 4: Vink
  • Leeruitkomsten (percentage toetsmatrijs tussen haakjes):
    • Dev-1: Kan Linux gebruiken (50%)
    • Dev-2: Kan relevante communicatie protocollen voor DevOps zoals DNS en RabbitMQ gebruiken (50%)
    • Dev-3: Kan Behaviour Driven Development toepassen (0%)
    • Dev-4: Kan software design lezen en Domain Driven Design toepassen (0%)

NB: Bij editie '21 zijn Dev-3 - BDD en Dev-4 - DDD getoetst en gedoceerd in DevOps toets en lessen, en was het 'protocol' RabbitMQ Exchanges (DNS, etcd. e.d. ook in DevOps). TODO voor '23/'24: Onderwerp Micro front-ends expliciet toevoegen. Missende inlevergelegenheid voor Wekelijkse huiswerkopdracht toevoegen in iSAS.

7.4 Toetsing DevOps Project (15 ECTS)

Beoordeling via beoordelingsmodel Projecten met 4 toetsmomenten:

• 10% Tussentijdse beoordeling Beoordeling. Geen minimumscore. Bestaande uit:
  • groepscijfer, op basis van kwantiteit en kwaliteit Beroepsproduct en DevOps groepsproces, zie team beoordeling
  • Verrekenen van individuele 'delta' op basis van individuele verantwoording schriftelijk en presentatie en observaties begeleiders (knock-out bij duidelijk te weinig inbreng), zie individuele beoordeling
• 90% Eindbeoordeling Beroepsproduct. Score minimaal een 5,5. Ook bestaande uit:
  • groepscijfer
  • en individuele delta of knock-out, zelfde als tussentijds

7.4.2 Toelichting afwijken reguliere AIM projectbeoordeling

De structuur met 4 toetsen tussentijds en eindcijfer en voor beide een groepscijfer en individuele beoordeling is hetzelfde als de reguliere AIM projectbeoordeling. Als minor vallen we hier niet onder, maar voor eenduidigheid is dit wel prettig.

De weging van cijfers gebeurt echter net anders, het eindcijfer is een optelling van groepscijfer en een individuele delta, eventueel negatief, of positief, maar doorgaans 0 (e.g. hele groep zelfde cijfer). De reguliere projectmethode gebruikt weegfactoren voor groepscijfer en individuele cijfer. Maar een vermenigvuldiging in plaats van simpele optelling van cijfers leidt tot minder intuitieve betekenis van delta. Want dit halveert voor het daadwerkelijke eindcijfer effectief de gegeven delta van de gekozen -1 tot +2 range naar de -0.5 naar +1 range.

Ook gelden groepscijfer en individueel niet beiden als knock-out voor eindcijfer, maar alleen de individuele cijfer. Dit kan door een negatieve delta waardoor je cijfer onder de 5,5 komt of het toekennen van de 1 of 4 absolute cijfers op basis van onvoldoende individuele bijdrage of verantwoording (e.g. knock-out). Dat een onvoldoende groepscijfer geen directe knock-out is, laat onverlet dat alle individuele teamleden verantwoordelijk zijn dit wel als signaal moeten zijn tijdig te communiceren met begeleiders en via samen bepaalde weg als team toch nog een groeps voldoende te behalen. Een eventuele neiging in zo'n situatie alleen voor de eigen individuele voldoende te gaan, zal leiden tot individueel alsnog onvoldoende beoordeling vanwege onvoldoende samenwerking en verantwoordelijkheidsgevoel. Als ondanks steken van voldoende aandacht hierin dit toch niet lukt, kan een evt. toegekende positieve delta evt. alsnog bepaalde groepsleden over de streep trekken.

8. Onderwijsmaterialen

• Online lesoverzicht
• Opdrachten via GitHub Classroom
• Committen en samenwerken via AIM interne Gitlab: https://gitlab.devops.aimsites.nl.
• Uploaden resultaten in iSAS
• Reader DevOps - Ian Sommerville (alleen beschikbaar voor AIM/minor studenten)
• Diverse Online documentatie tools (o.a. docker.com, kubernetes.io)
• TODO: PluralSight (via XTend kortingsdeal AIM)

Aangeraden naslagmateriaal (e.g. leestips van de docent)

• Boek Continuous Delivery, Jez Humble, David Farley
• The Phoenix project, Gene Kim

8. Ingangseisen

De minor is alleen toegankelijk voor HBO ICT studenten met een development profiel.

Vanwege het verdiepende karakter van de minor moet je ook een 4-e jaars student zijn. We gaan er van uit dat je bij aanvang van de minor je (meeloop) stage en verdiepende semester hebt afgerond. Op het moment van inschrijven voor de minor is dit idealiter ook zo, of ben je je verdiepende semester of (meeloop)stage aan het afronden.

Inhoudelijk gelden verder de onderstaand eisen over je voorkennis en vaardigheden. Deze heb je nodig om tijdens de minor verder uit te bouwen of om mee te kunnen werken in het beroepsproduct aan het eind van de course fase en het DevOps project in blok 2.

Om ze te onderscheiden van de TIJDENS de minor opgedane competentie zijn de competenties codes hieronder voorzien van een V- prefix.

Edit juni 2023: Op dit moment staat deelname in deze minor niet open voor ISM (infratructuur) studenten. Mogelijk verandert dit voor editie in 2024 of later en er zijn naast V-Dev competenties ook V-Ops competenties opgesteld. Om verwarring te voorkomen hebben we deze verwijderd (en in versiebeheer gestald). Deze kennis en vaardigheden zijn nodig tijdens de courses, maar ook tijdens het project, om een voldoende product op te kunnen leveren.

9.2 Vereiste voorkennis Developers

• V-Dev-1 Je kunt object geörienteerd programmeren in een getypeerde taal en kent enkele OO design patterns en kan deze herkennen en toepassen
• V-Dev-2 Je kunt geautomatiseerde unit en integratie tests schrijven met gebruikmaking van een test framework en -tool
• V-Dev-3 Je kunt ontwikkelen volgens Test Driven Development (TDD) en kent TDD patterns als Red-Green-Refactor, Arrange, Act, Assert en concepten als sut, mocks, stubs, etc.
• V-Dev-4 Je kent de werking van web protocollen als HTTP en DNS en dataformaten als XML en JSON
• V-Dev-5 Je kent de standaard 3-tier architectuur en principes van andere gelaagde architecturen
• V-Dev-6 Je kent basis UML technieken en kan requirements en technische documentatie samenstellen

Bronnen

• Linus Torvalds. z.d. Linux kernel coding style. geraadpleegd 9-2-2021 op https://www.kernel.org/doc/Documentation/process/coding-style.rst ^*

^*Merk op dat we hier afwijken van standaard APA conventie van `Achternaam, voorletters'en gewoon 'Linus Torvalds' schrijven. Dit is vanwege het vaak informelere 'je' en 'jij' binnen de ICT en ook het fenomeen van rockstar developers e.d. wel verantwoord. Je mag hieruit opmaken dat afwijken van standaarden best mag, mits expliciet gemaakt en met een goede argumentatie en afstemming vantevoren. Belangrijkste punt is dat je laat blijken de standaard WEL kent en hebt overwogen. Stem dit dus af met evt. beoordelaars.

Minor chartering

Door: Bart van der Wal, zomer 2021

Het toepassen van The Agile Inception Deck (AID) op de Minor DevOps zelf.

NB Een workshop van InfoSupport behandelt AID ook en in het project in blok 2 ga je dit ook gebruiken.

1. Describe why we are here

To do some major DevOps!

De DevOps beweging bestaat nu zo'n 10 jaar, en je ziet adoptie in groot deel van ICT bedrijfsleven, maar bij AIM (en voor zover mij bekend andere HBO ICT's) was er nog geen dedicated vak hierover, maar sijpelde het slechts hier en daar het onderwijs binnen via gebruik tools en om sneller aan de slag te kunnen.

2. Create an Elevator Pitch

"Let's do some major DevOps!" :)

In deze minor leer je moderne DevOps technieken en concepten om te kunnen innoveren en waarde toe te voegen in bedrijven. DevOps ligt in het verlengde van de Agile beweging, en geeft zeer veel tools, en best practices om als klein bedrijf een applicatie op schaal te draaien en om als groot bedrijf je complexe bedrijfsprocessen te modelleren, en te voorkomen dat tijd verloren gaat aan ICT complexiteit (accidental complexity) zodat je de gewonnen tijd kunt steken in het (via ICT) verbeteren van je bedrijfsvoering (inherente complexiteit).

3. Design a Product Box

Met het voltooien van een minor DevOps tijdens je studie ben je meer waard voor bedrijven en kun je sneller aan de slag in het ICT werkgebied. Interessante werkgevers hebben een hele categorie vacatures zals 'DevOps Engineer' en 'Site Reliability Engineer' (SRE), waarvoor je in aanmerking komt.

4. Create a NOT List

Extra: Ideeen Ops workshops 2022

• Package manager
• Running unit tests (writing Cucumber specs?)
• Managing DevOps
• CM: Ansible/CM

5. Meet Your Neighbors

Core team is jij, mede studenten, docenten AIM, docenten InfoSupport.

Buren/dependencies:

• aimsites.nl
• StackOverflow
• InfoSupport medewerkers
• Stackoverflow
• Academic license cloud services/trials

6. Show the Solution

Zie DevOps Tech.

7. Ask What Keeps Us Up at Night

• Is het te makkelijk?
• Is het te moeilijk?
• Operationele problemen

8. Size It Up

• 9 weken courses
• 9 weken project

9. Be Clear on What’s Going to Give

What's going to give? Nou in deze volgorde (tussen haakjes korte toelichting)

• 1. scope (minimale diepgang per onderwerp)
• 2. quality (6 niveau ligt vast)
• 3. time (vast, 9 weken)
• 4. money (n.v.t. behalve 'tijd is geld')

10. Show What It’s Going to Take

• Minimaal 20 studenten (max. 30)
• Een PluralSight account voor elke student
• Een voldoende krachtige laptop om lokaal
• VS Code, IntelliJ
• Nieuwsgierigheid, pragmatische insteek en een kritische blik
• Flexibiliteit en uren (40 uur per week, geen bijbanen)
• Goede en tijdige onderlinge communicatie
• Tijdige feedback en input

DevOps Minor voorlichting 20 apr 2023

AIM + InfoSupport

Start september 2023 (ma 28 augustus) Inschrijving sluit 30 april; zie verder kiesopmaat.nl.

$web-only$

DevOps overzicht in een paar plaatjes

Druk op alt+p (mac: Option+p) voor de slides. $web-only-end$

$slides-only$

Bronnen/Attributie

Alle bronnen/plaatjes gevonden of geraadpleegd op do 20 april 2023 :)

• Shift left https://www.testim.io/wp-content/uploads/2019/11/Shift-Left-Testing.png
• Wait... DevOps is Agile https://imgflip.com/i/7iu3it
• Agile Manifesto https://agilemanifesto.org/
• DevOps infinity https://opensenselabs.com/sites/default/files/inline-images/IC-DevOps-Loop-Illustrations.jpg
• DevOps is a culture, not a role https://twitter.com/OneUptimeHQ/status/1529463567673589763
• Basic DevOps Geraadpleegd op https://medium.com/@knoldus/opsinit-basic-understanding-of-devops-part-1-49dea74433fd

Blog

Hier vind je de blog posts van studenten van de minor DevOps over hun onderzoek naar technologien uit de Cloud Native Computing Foundation (CNCF) en andere DevOps tools, frameworks, talen etc.

Waar vind je verder nog zo'n verzameling Nederlandstalig DevOps blogs!? Die je helpen om de pareltjes te vinden, de disruptive technologies, tussen alle one day flies en de 'only buzz' tech.

Per 2022 zijn blog posts ook wel geschreven met hulp van ChatGPT. Maar moeten studenten wel door prompten en handmatig aanpassen totdat het ook echt zinnig is. Daarnaast presenteren studenten ook kort hun onderzoeksbevindingen in korte pitches die zij in teamverband geven. Mocht je hierbij aanwezig kunnen/willen zijn, dan zijn verzoeken welkom.

Met dank aan alle studenten!

Bart van der Wal, docent minor DevOps

Unit testen in Java met Maven Surefire en JUnit

Bart van der Wal, augustus 2024.

Dit is de Java/Spring Boot variant van de tutorial 'Unit testing C# in .NET using dotnet test and xUnit' op Microsoft Learn (2024). Deze tutorial toont een project opzet met een:

• unit test-project
• en een broncode-project

Om de tutorial te volgen met een vooraf opgebouwd project, kun je de voorbeeldcode op GitHub (van der Wal, 2024) bekijken of downloaden. We gaan er van uit dat je weet hoe dit werkt.

Hieronder eerst een toelichting over de wijzigingen t.o.v. de originele C# variant/tutorial en de context. Dit is ook interessant voor studenten die deze opdracht doen. Daarna 5 instructiestappen om te volgen meer specifiek voor Java Spring Boot variant. Hiervan is de laatste optioneel.

1. Toelichting

Deze tutorial is naast starter van de week opdracht ook een beetje een voorbeeld blog post, zoals je zelf in week 6 moet schrijven. Met in ieder geval een hands-on karakter via voorbeeld code om over te nemen en terminal commands om uit te voeren voor jou als lezer. Ook bevat deze APA referenties, zoals je zelf in de blog moet gebruiken. is in het Nederlands Alleen het 'onderzoekskarakter' is wellicht ondermaats als voorbeeld. Alhoewel ik hieronder wel wat beschouwingen doe en aansluit bij DevOps concepten zoals de DevOps roadmap en het Continuous Delivery Maturity Model (CDMM) die je ook een beetje, respectievelijk zelfs heel goed moet leren kennen in de minor.

Deze tutorial schreef ik naar aanleiding van minor DevOps 2024 waarin we licht varieren/diverisificeren t.o.v. eerdere edities. Dit in het kader van concept van 'Polyglot X' uit DevOps: dat microservices verschillende talen/frameworks kunnen gebruiken. Hiermee stijg je uit boven het basis niveau (Base level) uit het CDMM (een soort DevOps Maturity Model, InfoQ, 2013):

"Many organizations at the base maturity level will have a diversified technology stack but have started to consolidate the choice of technology and platform, this is important to get best value from the effort spent on automation."

Merk op dat er hierbij het checkpunt uit CDMM 'consolidate' (MinorDevOps, z.d.)) er wel een gemene deler Docker of Kubernetes is. Qua communicatie tussen de microservices is (gewoon via een) http API een standaard, maar in een latere week van de minor leren studenten ook een voorbeeld van een 'message bus' of (eigenlijk) 'message broker' namelijk RabbitMQ. ZO ga je naar meer advanced level van CDMM:

"...split the entire system into self contained components and adopt[ed] a strict api-based approach to inter-communication so that each component can be deployed and released individually." (InfoQ, 2013)

Figuur 1: Deel van DevOps roadmap wat aangepast naar context van minor DevOps (roadmap.sh, 2024)

De helft van de studenten (-teams/-duo's) doet de opdracht met .NET. De andere helft met Java, Spring Boot. In opdracht van week 2 ga je verder door de deze basis applicatie 'containerizen'.

2. Installeren scoop of SDKMan en dan Spring Boot CLI

We start een Java project met Spring Boot. Hierbij gebruiken we Maven als package manager zoals gebruikelijk bij Software Engineering op de HAN. Je bent misschien geneigd om IntelliJ te gebruiken. En voor het editen van code is dit prima, maar voor de herhaalbaarheid/scriptability ga je nu als DevOps-er, de initiele opzet via de commandline doen.

Installeer daarvoor de Spring Boot CLI (Command line interface) conform de instructies op de website (Spring Boot, z.d.): Maar het lijkt wel 'turtles all the way down', want voordat je Spring CLI kunt installeren (Spring Boot, z.d.) moet je eerst een package manager installeren, maar gebruik (en installeer) bv. scoop op Windows (scoop, z.d.), brew op macOS of sdkman als je Linux gebruikt.

Dit is een korte samenvatting voor Windows gebruikers (macOS en Linux komen er sowieso wel uit, toch?)

"Open een PowerShell terminal (version 5.1 or later) en vanaf de PS C:> prompt, run:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression

En daarna op de command line:

scoop bucket add extras
scoop install springboot

Bij onverhoopte errors, backtrace check de gegeven/originele bronnen/website voor installatie instructies, dit verandert vaak snel over de tijd.

3. Start Java Spring Boot project

Deze sectie beschrijft het maken van een Spring Boot Java project met de applicatie code en ook meteen een eigen test package. De project moet de volgende directory structuur en bestanden krijgen, conform standaard Maven structuur:

/priemtester
    pom.xml
    src/main/java/nl/han/devops/
        PriemTesterApplication.java
        PriemTester.java
    src/main/java/nl/han/devops
        PriemTesterTests.java

Figuur 2: Je zou de Spring Initializer in IntelliJ CLI kunnen gebruiken, maar...

Figuur 3: Beter: gebruik de Spring boot CLI, don't be afraid of the command line!

Voer onderstaand commando uit. Superkort is het ook niet meer, maar je customized meteen de package naam en naam van java klasse met je main(..) functie (dit wordt PriemTesterApplication).

spring init --build=maven --package-name=nl.han.devops priemtester

Je mag nu de applicatie is aangemaakt deze wel openen in IntelliJ IDEA. Installeer deze als je deze nog niet hebt staan (best meteen Ultimate editie via je HAN student e-mail). Of navigeer naar je project directory en open deze in de VS Code editor:

cd priemtester
code .

4. Make it your own!

Hernoem DemoApplication.java naar PriemTesterApplication.java.

Maak een nieuwe klasse PriemTester.java met de volgende code:

package nl.han.devops;

public class PriemTester {
    public boolean isPriemgetal(int candidate) {
        throw new UnsupportedOperationException("Nog niet geïmplementeerd.");
    }

}

Aangezien we een unit test gaan schrijven van de 'domein' logica, en NIET de gehele Applicatie (dat zou een integratietest zijn) hernoem ook de DemoApplicationTests.java naar PriemTesterTests.java om deze te 'repurposen'. Verwijder dan ook de gegenereerde contextLoads() methode, die hier dan niet meer thuishoort.

Deze code gooit nu een UnsupportedOperationException met een bericht dat deze methode nog geimplementeerd is. Op deze manier compileert de code wel, en kun je het runnen, maar is duidelijk wat er aan de hand is, ook als je dit stuk code een paar dagen laat liggen, en dan pas weer terug komt. Maar nu gaan we dit gaan we al veel sneller aanpassen ;).

De NIET TDD manier om de code te runnen/testen zou zijn om in je main de nieuwe methode aan te roepen. Je kunt even tijdelijk de code in je main methode in PriemTesterApplication.java als volgt maken, aangezien deze nu nog niet echt iets doet, en om wel te checken of je nog Java programma's kunt runnen ;). Maar verwijder deze code daarna weer.

   public static void main(String[] args) {
      SpringApplication.run(PriemTesterApplication.class, args);

      // Tijdelijke test code.
      var priemTester = new PriemTester();
      for(int i = 0; i<10; i++) {
      System.out.println("Getal " + i + " is een priemgetal?" + priemTester.isPriemgetal(i));
      // Einde tijdelijke test code, beter via TDD
   }
}

We gaan nu unit tests gebruiken als entry points in plaats van de main methode. Zo kom je ook netjes tot TDD: Test Driven Development, zoals verplicht in deze minor! En 'vervuil' je je main methode niet met test code.

5. Maak een test, TDD all the way!

Een populaire aanpak in testgestuurde ontwikkeling (TDD) is om eerst een (mislukkende) test te schrijven voordat de doelcode wordt geïmplementeerd. Deze tutorial gebruikt de TDD-aanpak. De methode IsPrime kan worden aangeroepen, maar is niet geïmplementeerd. Een testaanroep naar IsPrime faalt. Bij TDD wordt een test geschreven waarvan bekend is dat deze zal falen. De doelcode wordt vervolgens bijgewerkt om de test te laten slagen. Je herhaalt deze aanpak steeds opnieuw: je schrijft een falende test en werkt daarna de doelcode bij om te slagen.

Vul de code in PriemTesterApplicationTests met test methodes voor input 1 en 2. Later komen er meer methodes in de verzameling tests. Zo'n verzameling tests noemt men ook wel een test suite.

NB: Dit woorde 'suite' in 'test suite' spreek je ANDERS uit dan het woord 'suit' (=pak), wat veel mensen foutief zeggen. Je zegt 'suite' meer als 'zwiete' (of 'sweet' in het Engels). Luister anders eens op Google Translate naar het Nederlands en evt. ook de Engelse variant, via de volgende link:

https://translate.google.com/?sl=nl&tl=en&text=test%20suite&op=translate (als developer/devopser moet je ook kunnen praten over je vak, dus probeer hier zelf eens zinnen of woorden uit als je twijfelt hoe je ze uitspreekt)

@SpringBootTest
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class PriemTesterApplicationTests {

  PriemTester sut;

  @BeforeAll
  void beforeAll() {
    sut = new PriemTester();
  }

  @Test
  void PriemTester_1_is_geen_priemgetal() {
    // Arrange.
    // TODO Refactoren dit soort herhalende code.
    // DAMP: DRY voor unit tests: Descriptive And Meaningfull Phrases.
    sut = new PriemTester();

    var input = 1;
    var expected = false;

    // Act.
    var actual = sut.isPriemgetal(input);

    // Assert.
    Assertions.assertEquals(expected, actual);
  }

  @Test
  void PriemTester_2_is_een_priemgetal() {
    // Arrange.
    // TODO Refactoren dit soort herhalende code.
    // DAMP: DRY voor unit tests: Descriptive And Meaningfull Phrases.
    sut = new PriemTester();

    var input = 2;
    var expected = true;

    // Act.
    var actual = sut.isPriemgetal(input);

    // Assert.
    Assertions.assertEquals(expected, actual);
}

De @Test annotatie maakt een methode als een test methode die gerund wordt door de 'test runner'. De naam van een test methode maakt technisch niet uit, maar het is belangrijk deze een beschrijvende naam te geven.

Verder biedt JUnit ook de @BeforeEach en @BeforeAll annotatie die telkens voor elke test (in de testsuite) respectievelijk eenmaal voor start van op de (gelijknamige) methode)

Run mvn test. En/of gebruik de 'play' toets op toetsmethodes in je editor/IDE.

Los de TODO's op door herhalende code te refactoren naar de BeforeAll. En run de tests opnieuw om te checken dat alles nog werkt.

Breidt nu de applicatie code isPriemgetal uit met de volgende code:

public boolean isPriemgetal(int kandidaat) {
    if (kandidaat == 1) {
        return false;
    }
    throw new UnsupportedOperationException("Niet geheel geïmplementeerd.");
}

Run weer de tests.

6. Meer testgevallen via parametriseren testmethode

Voeg tests toe voor input 0 en -1. Je kan verder gaan copy-pasten en wat aanpassen. Maar dat is niet DRY (Don't Repeat Yourself), maar WET (Write Everything Twice). Er is een betere manier!

bool result = sut.IsPrime(1);

Assert.False(result, "1 zou geen priemgetal moeten zijn");

Er bestaan nog extra JUnit annotaties die het mogelijk maken een suite van vergelijkbare tests op te stellen.

Je kunt gebruik maken van @ParameterizedTest om een reeks tests uit te voeren met verschillende invoerargumenten. De annotatie @ValueSource specificeert de waarden voor die invoer. In plaats van afzonderlijke test methodes te schrijven, gebruik je deze JUnit annotaties om één enkele testtheorie te creëren. Als volgt:

package nl.han.devops;

import org.junit.jupiter.api.*;

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;
import org.springframework.boot.test.context.SpringBootTest;

@SpringBootTest
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
public class PriemTesterTest {

  private final PriemTester priemTester = new PriemTester();

  @ParameterizedTest
  @ValueSource(ints = {-1, 0, 1, 2})
  public void isPriemgetal_WaardenKleinerDan2_ReturnFalse(int value) {
    boolean result = priemTester.isPriemgetal(value);

    Assertions.assertFalse(result, value + " zou geen priemgetal moeten zijn");
  }
}

NB Conform lessen uit het 1e Semester van Software Engineering, is het goed de priemTester variabele in bovenstaande code te hernoemen naar sut om evident te maken dat de PriemTester klasse de system under test is in deze unit test.

Run mvn test en twee van de testen zullen falen. Om alle tests te laten slagen, update de IsPriem methode met de volgende code:

public bool IsPriemgetal(int kandidaat) {
    if (kandidaat < 2) {
        return false;
    }
    throw new NotImplementedException("Not fully implemented.");
}

Volg de TDD aanpak, en voeg meer falende testen toe, en update de applicatie code. Zie evt. de uiteindelijke versie van de implementatie op GitHub.

Let op: Deze IsPriem methode is GEEN efficient algoritme om te testen of een getal een priemgetal is (hiervoor kun je best een bestaande oplossing/package uit NuGet of MavenCentral repository halen).

7. Optionele extra opdracht: Make it fast.

Binnen Software Engineering, en ook in deze minor, richten we ons vooral op de 'make it work' fase en dan de 'make it nice' fase uit het bekende adagium van Beck's bekende gezegde over code:

Figuur 4: "Make it work, make it nice, make it fast." - Kent Beck, z.d. (TODO: APA), Bron plaatje: the tombomb

Maar voor de liefhebbers, die eens willen kijken naar 'make it fast'. Best manier is toch dit van andere te jatten, en je eigen originaliteit te bewaren voor onopgeloste problemen (of oplossing van bestaande problemen toepassen in nieuwe domeinen, waar niemand dit probleem al echt heeft gezien ... 😉 💶).

Voor een WEL efficiente methode, of in ieder geval efficientere aanpak zoek zelf een package in NuGet of Maven central, bestudeer de README/documentatie of community feedback of deze goed is, en voeg hiervan de URL als bron toe. En voeg een variant toe van deze implementatie. Liefst via eerst extracten van een interface uit je huidige PriemTester (met refactor optie van IntelliJ bv; of anders handmatig. Deze interface noem je PriemTester en je huidige implementatie hernoem je naar CustomPriemTester. Dan maak je een nieuwe implementatie EfficientPriemTester, en hierin roep je de Maven package aan. Feitelijk is dit nu een.... Adapter patroon). Later zou je een load test kunnen bouwen, om de twee implementaties op performance/snelheidsverschillen te kunnen testen.

Bronnen

• InfoQ (2013). The Continuous Delivery Maturity Model. Geraadpleegd 27 augustus 2024 op https://www.infoq.com/articles/Continuous-Delivery-Maturity-Model/
• Minor DevOps (z.d.) Beoordelingsmodel Groep. Geraadpleegd op 27-8-2024 op https://minordevops.nl/beoordelingsmodel-groep.html
• Microsoft Learn (3-7-2024) Unit testing with dotnet test and xUnit. Geraadpleegd op 27 augustus op https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-with-dotnet-test
• Scoop.sh (z.d.) Scoop geraadpleegd op 2 september 2024 op https://scoop.sh/
• Spring Docs (z.d.) Installing the CLI :: Spring Boot, Geraadspleegd op 27-8-2024 op https://docs.spring.io/spring-boot/cli/installation.html
• Spring.io (z.d.) Installing Spring Boot CLI geraadpleegd op 2 september 2024 op https://docs.spring.io/spring-boot/installing.html#getting-started.installing.cli
• Wal, B. van der. (2 september 2024) Priemtester code. geraadpleegd op 2 september 2024 op https://github.com/hanaim-devops/priemtester

Microservices: The complete saga (compensating transactions)

Yorrick Bakker, oktober 2021.

Allereerst leg ik de aanleiding voor deze blog uit door te bespreken waarom transacties en microservices niet vanzelfsprekend hand-in-hand gaan. Daarna licht ik toe wat compensating transactions en het saga pattern precies inhouden, waarna ik een voorbeeldimplementatie van het saga pattern laat zien.

Deze blog is geschreven in opdracht van de Hogeschool van Arnhem en Nijmegen tijdens de Minor DevOps.

Transacties en microservices

Het gebruik van transacties in een database is een welbekende en veelgebruikte techniek om een aantal samenhangende operaties uit te voeren die óf allemaal slagen óf allemaal falen. Een belangrijk aspect van een transactie is dat deze atomair is. Dit houdt in dat de data die een transactie aanpast pas in de database gecommit wordt op het moment dat de transactie succesvol is afgerond. Een "half-afgeronde" transactie bestaat dus niet (Microsoft, 2018).

Het gebruik van een microservice-architectuur biedt op veel vlakken voordelen. Helaas bemoeilijkt het gedistribueerde karakter van microservices het gebruik van transacties enorm. Sterker nog, het is meestal onmogelijk om een ACID-compliant transactie over verschillende microservice-databases uit te voeren (Microsoft, z.d.).

Er zijn verschillende strategieën om transacties toe te passen in een microservice-architectuur. In dit artikel richt ik me op het saga pattern met compensating transactions. Het is belangrijk om te noemen dat deze transacties nog steeds niet ACID-compliant zijn. "Atomicity" en "Isolation" kunnen meestal niet gegarandeerd worden. In plaats daarvan zijn de transacties BASE-compliant:

• Basically Available
• Soft state
• Eventually consistent

Hierbij is vooral het concept eventual consistency belangrijk. Dit concept houdt in dat een wijziging niet direct zichtbaar is, maar na verloop van tijd wel gegarandeerd overal doorgevoerd wordt (ScyllaDB, 2021).

Compensating transactions

Als je gedistribueerde transacties gaat implementeren wordt het concept van compensating transactions erg belangrijk. Een compensating transaction is een idempotente actie die precies het tegenovergestelde doet van een bepaalde stap in de transactie. Elke actie binnen een transactie heeft dan ook een eigen compensating action (Microsoft, 2017). Dit is een voorbeeld van een gedistribueerde transactie:

Als voorbeeld gebruik ik een fictieve reisorganisatie. Een klant kan hier een (volledig willekeurige) reis boeken. Om dit te bereiken moet er met drie services gecommuniceerd worden. Als er een stap mislukt wordt de compensating action van die stap aangeroepen. Als er bijvoorbeeld iets misgaat bij het reserveren van de huurauto wordt de reservering geannuleerd en de vlucht geannuleerd. Het systeem bevindt zich dan weer in de staat waarin het zich voor het begin van de transactie bevond.

Uit dit diagram blijkt ook het belang van idempotentie. Het is namelijk ook mogelijk dat een compensating action faalt. Het is dus erg belangrijk dat de actie net zo lang herhaald kan worden tot deze slaagt.

Saga pattern

Een manier waarop je gedistribueerde transacties met compensating transactions kan implementeren is met behulp van het saga pattern (IBM, z.d.). Je kan het saga pattern op twee manieren implementeren, namelijk choreography-based en orchestration-based (Richardson, z.d.). Beide strategieën hebben voor- en nadelen. Dit is een interessante talk van Caitie McCaffrey over het toepassen van het saga pattern voor het verwerken van statistieken van de game Halo. Caitie heeft het hier specifiek over een orchestration-based saga.

Choreography-based

De choreography-based saga is de meest eenvoudige manier om het saga pattern te implementeren. In deze situatie "weet" elke service wat de volgende stap in de transactie is. Nadat een service zijn stap succesvol heeft uitgevoerd is hij zelf verantwoordelijk voor het aanroepen van de volgende service. Hetzelfde geldt voor een niet-succesvol afgeronde stap. De service voert zijn eigen compensating action uit en roept de volgende compensating action aan. De architectuur van een choreography-based saga ziet er dus precies uit zoals het plaatje hierboven (Microsoft, z.d.).

Het voordeel van een choreography-based saga is dat het eenvoudig te implementeren is in een kleine architectuur. Er is geen single point of failure, elke service heeft namelijk evenveel verantwoordelijkheid bij het uitvoeren van de transactie. Een nadeel is echter dat het lastig te traceren is waar de transactie zich op dit moment bevindt. Ook het uitbreiden of wijzigen van een transactie wordt al snel complex (Richardson, z.d.).

Orchestration-based

Een orchestration-based saga introduceert een nieuw concept: de orchestrator of saga execution coordinator (SEC). De SEC houdt alle transacties bij, weet welke stappen er volgen en in welke staat een transactie zich bevindt. De orchestrator is verwantwoordelijk voor het aanroepen van services, maar dus ook het uitvoeren van de compensating transaction wanneer een actie faalt. Het voordeel van deze gecentraliseerde aanpak is dat het een stuk makkelijker is om uit te vinden in welke staat een transactie zich bevindt. De SEC houdt dit namelijk precies bij. Daarnaast is het uitbreiden of wijzigen van een transactie eenvoudiger, aangezien dit alleen in de saga execution coordinator aangepast hoeft te worden. Het nadeel is dat er een single point of failure geïntroduceerd wordt (Richardson, z.d.).

De SEC kan je als losse service deployen. Een andere optie is om deze in een andere service te embedden. Dit kan bijvoorbeeld de eerste service in een transactie zijn.

Voorbeeldimplementatie

Om een voorbeeld te demonstreren van een saga gebruik ik mijn eerdere voorbeeld van een fictief reisbureau. De voorbeeldcode kan je hier vinden. Instructies voor het uitvoeren staan in de README. De architectuur ziet er als volgt uit:

NB: Ik gebruik RabbitMQ om tussen services te communiceren. Het gebruik van een message queue is geen vereiste bij het gebruik van het saga pattern. Ik gebruik het hier wel omdat dat gebruikelijk is bij een microservice-architectuur.

Vanwege de grootte van deze architectuur kies ik ervoor om gebruik te maken van een choreography-based saga. Dit is de flow van de transactie:

1. De controller van ReisAPI start een transactie op het moment dat iemand POST naar /reizen
2. De TicketService boekt een vliegticket
3. De HuurautoService reserveert een huurauto
4. De HotelService boekt een hotel

Wanneer er iets fout gaat in een service zal de service eerst zijn eigen actie compenseren, waarna hij de compenserende actie van de vorige service aanroept. Zo ziet het begin van de transactie in ReisAPI (ReizenController.cs) er uit:

using (connection)
{
    using var channel = connection.CreateModel();
    channel.ExchangeDeclare("saga", ExchangeType.Topic, true);
    Message message = new() 
    {
        Id = Guid.NewGuid().ToString()
    };
    channel.BasicPublish("saga", "saga.ticketservice.execute", null,
        Encoding.UTF8.GetBytes(JsonSerializer.Serialize(message)));
}

De ReisAPI publiceert een nieuw bericht op het saga topic met routing key saga.ticketservice.execute. Op het moment dat het uitvoeren van de actie foutgaat zal de service zijn actie ongedaan maken. Indien er een vorige stap in de transactie was zal de service een bericht publiceren met routing key saga.[servicenaam].compensate. Op die manier hoeft een service dus alleen aan de topic saga.[servicenaam].* te binden. Deze strategie zorgt er ook voor dat een eventuele uitbreiding naar een gecentraliseerde aanpak een stuk makkelijker wordt. Deze service hoeft dan alleen aan de topic saga.*.* te binden.

Elke service heeft een Execute() methode, in dit geval om duidelijk te maken dat dat de stap in de transactie is die uitgevoerd wordt:

async Task Execute(Message message)
{
    Console.WriteLine($"Started executing HotelService for {message.Id}");
    await collection.InsertOneAsync(message);
    var rand = new Random();
    if (rand.Next(10) < 7) throw new Exception();
    Console.WriteLine($"Executed HotelService for {message.Id}");
    Next(message);
}

De Execute() methode van HotelService (HotelService/Program.cs) simuleert (in 70% van de gevallen) een fout in het uitvoeren, waarna door een bovenliggende try/catch de compenserende actie wordt aangeroepen. Dat is in dit geval het ongedaan maken van de Insert in de database.

Daarnaast krijgt elke service een Next() methode, deze wordt aangeroepen zodra de stap in de transactie van die service voltooid is. Elke service weet dus wat de volgende stap in de transactie is, en publiceert in dit geval een nieuw bericht op de message queue.

void Next(Message message)
{
    channel.BasicPublish("saga", "saga.hotelservice.execute", null,
        Encoding.UTF8.GetBytes(JsonSerializer.Serialize(message)));
}

Uiteraard heeft elke service ook een manier om zijn actie te compenseren en terug te gaan naar de vorige stap in de transactie. De methode Compensate() maakt de actie ongedaan en Previous() roept de vorige service aan:

async Task Compensate(Message message)
{
    Console.WriteLine($"Started compensating HuurautoService for {message.Id}");
    var rand = new Random();
    if (rand.Next(10) < 7)
    {
        Console.WriteLine($"Compensation of HuurautoService failed for {message.Id}! Retrying...");
        throw new Exception();
    }
    await collection.DeleteOneAsync(document => document.Id == message.Id);
    Console.WriteLine($"Compensated HuurautoService for {message.Id}");
    Previous(message);
}

void Previous(Message message)
{
    channel.BasicPublish("saga", "saga.ticketservice.compensate", null,
        Encoding.UTF8.GetBytes(JsonSerializer.Serialize(message)));
}

In dit geval simuleert HuurautoService (HuurautoService/Program.cs) het falen van een compensating action. De aanroep van de Compensate() actie ziet er zo uit:

await Policy
    .Handle<Exception>()
    .WaitAndRetryForeverAsync(i => TimeSpan.FromSeconds(1))
    .ExecuteAsync(async () => await Compensate(parsed!));

Wanneer de compensating action faalt zal deze net zolang herhaald worden tot 'ie slaagt. Ik heb Polly gebruikt voor deze foutafhandeling. Als een transactie succesvol wordt afgerond zien de logs er zo uit:

reisapi_1             | Started transaction 1670771a-29ca-4d53-a5e9-e46f913529a5
ticketservice_1       | Started executing TicketService for 1670771a-29ca-4d53-a5e9-e46f913529a5
ticketservice_1       | Executed TicketService for 1670771a-29ca-4d53-a5e9-e46f913529a5
huurautoservice_1     | Started executing HuurautoService for 1670771a-29ca-4d53-a5e9-e46f913529a5
huurautoservice_1     | Executed HuurautoService for 1670771a-29ca-4d53-a5e9-e46f913529a5
hotelservice_1        | Started executing HotelService for 1670771a-29ca-4d53-a5e9-e46f913529a5
hotelservice_1        | Executed HotelService for 1670771a-29ca-4d53-a5e9-e46f913529a5
hotelservice_1        | Completed transaction 1670771a-29ca-4d53-a5e9-e46f913529a5

Elke service voert dus zijn eigen stap uit en "geeft het stokje door" naar de volgende service in de transactie. Wanneer er iets fout gaat ziet het er zo uit:

reisapi_1             | Started transaction 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
ticketservice_1       | Started executing TicketService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
ticketservice_1       | Executed TicketService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
huurautoservice_1     | Started executing HuurautoService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
huurautoservice_1     | Executed HuurautoService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
hotelservice_1        | Started executing HotelService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
hotelservice_1        | Started compensating HotelService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
hotelservice_1        | Compensated HotelService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
huurautoservice_1     | Started compensating HuurautoService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
huurautoservice_1     | Compensation of HuurautoService failed for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae! Retrying...
huurautoservice_1     | Started compensating HuurautoService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
huurautoservice_1     | Compensation of HuurautoService failed for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae! Retrying...
huurautoservice_1     | Started compensating HuurautoService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
huurautoservice_1     | Compensated HuurautoService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
ticketservice_1       | Started compensating TicketService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
ticketservice_1       | Compensated TicketService for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae
ticketservice_1       | Compensated transaction for 0674aa00-5aec-4c5e-b265-b7db47d9f1ae successfully.

In dit geval gaat er iets fout in HotelService. De service maakt eerst zijn eigen actie ongedaan en roept vervolgens de compensating action van HuurautoService aan. Deze gaat vervolgens fout en wordt net zo lang herhaald totdat hij slaagt. Uiteindelijk is de compensating transaction afgerond en is alle data die in de database was opgeslagen nu weer verwijderd. Dit kan je verifiëren door naar localhost:8081 te gaan en de TicketService database te bekijken. Hier staan alleen documenten waarvan de gehele transactie is geslaagd.

Conclusie

Het is relatief eenvoudig om het saga pattern toe te passen in een bestaande microservice-architectuur. In veel gevallen zal het echter niet zo eenvoudig zijn als mijn voorbeeldimplementatie. In een complexere architectuur met veel verschillende transacties is het waarschijnlijk beter om voor een gecentraliseerde aanpak — het orchestrated saga pattern — te kiezen. Deze blog biedt echter een goede basis voor het begrip en implementeren van compensating transactions en het saga pattern.

Bronnen

• Microsoft (2018, 31 mei). What is a Transaction? - Win32 apps. Microsoft Docs. Geraadpleegd oktober 2021 van https://docs.microsoft.com/en-us/windows/win32/ktm/what-is-a-transaction

• Microsoft. (z.d.). Saga distributed transactions - Azure Design Patterns. Microsoft Docs. Geraadpleegd oktober 2021 van https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/saga/saga

• ScyllaDB. (2021, 23 juni). What is Eventual Consistency? Definition & FAQs. Geraadpleegd oktober 2021 van https://www.scylladb.com/glossary/eventual-consistency/

• Microsoft. (2017, 23 juni). Compensating Transaction pattern - Cloud Design Patterns. Microsoft Docs. Geraadpleegd oktober 2021 van https://docs.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction

• IBM. (z.d.). Solving distributed transaction management problem in microservices architecture using Saga. IBM Developer. Geraadpleegd op 7 oktober 2021 van https://developer.ibm.com/articles/use-saga-to-solve-distributed-transaction-management-problems-in-a-microservices-architecture/

• Richardson, C. (z.d.). Sagas. microservices.io. Geraadpleegd op 7 oktober 2021 van https://microservices.io/patterns/data/saga.html

Ansible: Configureren zonder nieuwe dingen te leren

Sven van Beek, oktober 2021.

Dit blog legt eerst uit wat Ansible is en welke problemen het voor je kan oplossen, hierna volgt een hands-on onderdeel met opzet van een Nginx webserver vanuit een Docker container gedeployed naar localhost. Tenslotte een vergelijking van Ansible met andere tools en verschillende redenen gegeven om voor Ansible te kiezen.

Wat is Ansible?

Ansible (RedHat, z.d.) is een automatiseringsplatform dat is opgericht in 2012. Het is oorspronkelijk ontwikkeld door Michael deHaan maar inmiddels is het een gratis open-source tool die beheerd wordt door de Ansible community en wordt het gesponsord door RedHat. Het is hoofdzakelijk geschreven in Python en draait op alle Unix gebaseerde systemen (Linux, MacOs, enz.) en Windows (Wikipedia, 2021).

Ansible is in tegenstelling tot andere configuratiemanagement tools agentless. In plaats hiervan maak je verbinding met de verschillende nodes door middel van een SSH key. Verder maakt Ansible gebruik van YAML bestanden met een taal dat sterk lijkt op Engels (Hummel, 2019) (Higbee, 2020).

Waar kan Ansible bij helpen?

Ansible kan helpen bij het opzetten en beheren van meerdere services door middel van één configuratie. Hierdoor hoeft bij het schalen van services niemand handmatig de server in te richten, maar doet Ansible dit voor je (Orchestration). Door deze aanpak kan een service binnen enkele seconden gebouwd worden.

Verder kan het helpen bij het configureren van de verschillende services. Dit gebeurd op basis van het ‘push’ principe. De main server, vaak een lokale computer, pusht updates van de configuratie naar de follower servers (Configuration management).

Hiernaast kan Ansible je helpen bij het automatiseren van deployments op verschillende omgevingen (Automatic deployment). Hierdoor ontstaat een kortere ‘time to market’ (Hummel, 2019) (simplilearn, 2019) (Higbee, 2020).

Waarom is Ansible een echte DevOps tool?

Ansible is een automatiseringstool die het mogelijk maakt om aan het principe Infrastructure as Code (IaC) te voldoen. IaC is het proces van het beheren en inrichten van computerdatacenters via machineleesbare definitiebestanden, in plaats van fysieke hardware configuratie of interactieve configuratietools. IaC is een best practices in DevOps, het betrekt ontwikkelaars meer bij het definiëren van configuratie en Ops-medewerkers eerder tijdens het ontwikkelingsproces. Automatisering in het algemeen heeft tot doel het verwarrings- en foutgevoelige aspect van handmatige processen weg te nemen en efficiënter en productiever te maken. Dit is ook wat Ansible doet door configuratiefiles te maken. Hierdoor kunnen betere software en applicaties worden gemaakt met flexibiliteit en minder downtime (Ahmed, 2020).

De Ansible configuratiemanager structuur

De configuratiemanager van Ansible heeft een duidelijke en eenvoudige structuur zoals is weergegeven in Afbeelding 1.

Afbeelding 1: Ansible configuratiestructuur

In Afbeelding 1 is te zien dat er één management node is, dit kan gewoon een lokale laptop zijn. Op deze node wordt Ansible geïnstalleerd. Daarnaast worden op deze node een host file en één of meerdere playbooks aangemaakt. Een playbook is de configuratie file voor de services. Binnen deze file worden de taken omschreven die uitgevoerd moeten worden. De Main node maakt vervolgens een connectie naar het IP adres van de follower nodes via een SSH verbinding, de IP adressen van de follower nodes staat beschreven in de host file. De follower nodes hebben hierdoor geen enkele kennis van Ansible en het playbook nodig (Dittrich, z.d.).

Het configureren van twee nodes door middel van Ansible

Zoals eerder besproken, is het mogelijk om de configuratie van alle aangesloten nodes te regelen. In dit hoofdstuk wordt een demo uitgevoerd om een Nginx webserver op te zetten en te deployen op localhost:8080 vanuit een docker container. In deze demo wordt gebruik gemaakt van twee ubuntu:20.04.3 LTS versie nodes (VM). Een van deze virtual machines is als management node (Main) aangewezen en de andere VM is de Follower node.

Het installeren van Ansible

Door middel van een aantal commando's kan Ansible worden geinstalleerd op de Main node. Eerst update je de packagemanager door middel van het commando sudo apt-get update. Nu kun je Ansible installeren sudo apt install ansible -y. Om te controleren of Ansible juist geïnstalleerd is kan je het commando ansible –version uitvoere. Wanneer de response vergelijkbaar is met Afbeelding 2, is Ansible correct geïnstalleerd (Higbee, 2020).

Afbeelding 2: Ansible installed response

Het configureren van Ansible en SSH

Om Ansible te configureren en naar het juiste IP adres van de Follower te laten verwijzen, dien je eerst het IP adres van de Follower op te vragen. Dit kun je doen door het commando ifconfig uit te voeren op de Follower node. In de onderstaande afbeelding is het IP adres van de service zichtbaar die je later gebruikt in de host file van de Main node.

Afbeelding 3: ifconfig response

Hiernaast dien je een SSH key aan te maken, dit werkt op iedere distributie van Linux anders, voor ubuntu kun je de volgende commando’s uitvoeren op de Follower node

sudo apt-get update

sudo apt-get install openssh-server

sudo systemctl status ssh

sudo ufw allow ssh

ssh username@ip_address 

voer ‘yes’ in
voer een wachtwoord in

Hierna dien je te wisselen naar de Main node. Wanneer de wens is dat de configuratie ook op de Main node wordt uitgevoerd, kunn je de bovenstaande stappen ook hierop uitvoeren. Hierna kun je de Ansible host file aanpassen om een connectie te maken met de Follower nodes. Dit kan door sudo nano /etc/ansible/hosts uit te voeren. In deze file moeten de volgende regels toegevoegd worden. (Linuxize, 2019)

Afbeelding 4: Ansible host file

Het aanmaken van een playbook in Ansible

Het aanmaken van een Ansible playbook kan met elke tekst editor, de structuur van het bestand is makkelijk te begrijpen en de taal lijkt op Engels. Het aanmaken van een playbook.yml gaat door middel van het commando sudo nano playbook.yml hierna kun je het playbook.yml bestand vullen met een aantal taken die chronologisch worden uitgevoerd. Voor het pullen en deployen van de nginx docker container ziet het playbook.yml er zo uit:

---
- name: docker_install_nginx
  hosts: ansible_clients
  become: true

  tasks:
   - name: Install aptitude using apt
     apt: name=aptitude state=latest update_cache=yes force_apt_get=yes

   - name: Install required system packages
     apt: name=docker state=latest update_cache=yes
     loop: [ 'apt-transport-https', 'ca-certificates', 'curl', 'software-properties-common', 'python3-pip', 'virtualenv', 'python3-setuptools']

   - name: Add Docker GPG apt Key
     apt_key:
      url: https://download.docker.com/linux/ubuntu/gpg
      state: present

   - name: Add Docker Repository
     apt_repository:
       repo: deb https://download.docker.com/linux/ubuntu bionic stable
       state: present

   - name: Update apt and install docker-ce
     apt: update_cache=yes name=docker-ce state=latest

   - name: Install Python pip
     apt: name=pip update_cache=true state=present force_apt_get=yes
     with_items:
     - python-pip
     - python3-pip
     become: true

   - name: Install Docker Module for Python
     pip:
       name: docker

   - name: Pull nginx Docker image
     docker_image:
       name: "nginx"
       source: pull
   - name: Create default containers
     docker_container:
       name: "nginx_container"
       image: "nginx"
       state: started
       recreate: yes
       published_ports:
        - "8080:80"

Elke playbook file moet beginnen met --- hierna volgt de host informatie (deze is gelijk aan de groep name uit de host file). Hierna volgt het keyword tasks met daaronder alle taken die beginnen met een -. Eerst worden een aantal packages geïnstalleerd die nodig zijn om Docker te installeren. Vervolgens wordt Docker zelf geïnstalleerd en wordt de Nginx image opgehaald. Tenslotte wordt een container gestart op poort 8080. Let op dat voor iedere OS of distributie de commando’s om te installeren anders kunnen zijn. Verder dien je tekst te laten inspringen in de playbook file. (Kataria, z.d.) (simplilearn, 2019)

Het uitvoeren van een playbook in Ansible

Het uitvoeren van een playbook in Ansible gaat door middel van het commando ansible-playbook playbook.yml -kK. Na het uitvoeren van het commando is een soort gelijk scherm te zien als in Afbeelding 5. (simplilearn, 2019)

Afbeelding 5: Ansible run playbook response

Vervolgens kan je een browser openen op de Follower node en http://localhost:8080 bezoeken. Daar zie je dan de startpagina van nginx:

Afbeelding 6: Nginx running op localhost:8080

Waarom kiezen voor Ansible?

Een van de grootste voordelen aan Ansible vergeleken met andere configuratiemanagement tools is dat Ansible agentless is. Dat wil zeggen dat je op de follower nodes geen agent hoeft te installeren. Hier zitten twee voordelen aan:

• Er blijft meer ruimte en kracht over op de follower node, hier draait immers geen agent die deze ruimte opvult
• De follower nodes hebben geen enkele kennis van Ansible en kun je direct vervangen zonder ze verder in te stellen

Een ander voordeel is dat playbooks gemakkelijk te lezen en schrijven zijn. Dit komt omdat ze geschreven worden in bijna natuurlijk Engels. Andere tools gebruiken hiervoor vaak programmeertalen wat het ingewikkelder maakt.

Ook is Ansible open-source, heeft het een grote community en het wordt gesponsord door RedHat. Hierdoor is er veel onderhoud en zijn er veel nieuwe features.

In vergelijking met andere tools is Ansible declaratief en niet procedureel. Dit betekent dat de beschrijving de eindtoestand van de machine bevat en dat Ansible alle nodige stappen onderneemt om aan die beschrijving te voldoen. Door op deze manier te werken, kunnen playbooks meerdere keren worden toegepast zonder dat dit bijwerkingen oplevert (Delgehier, 2020).

Een laatste voordeel is dat Ansible ook beschikt over een user interface, namelijk Ansible Tower. Ansible Tower is de extra ‘laag’ bovenop Ansible die complexe IT-infrastructuren inzichtelijk en beheersbaar maakt. De voordelen van Ansible Tower zijn:

• Ultieme controle over uw IT infra met een helder, visueel dashboard
• Role-based access control
• Taakverdeling
• Gecentraliseerde logging
• Ingebouwde notificaties
• Mogelijkheid om Tower overal te integreren met behulp van de API

Een groot nadeel aan Ansible Tower is dat het niet gratis is en dat het flink in de kosten kan lopen (Proxy, 2020).

Is Ansible de onmisbare DevOps tool?

Kortom, Ansible is de onmisbare configuratiemanagement tool. Een configuratiemanagement tool is binnen de wereld van DevOps van ultiem belang en Ansible biedt flink wat voordelen tegenover traditionele configuratiemanagement tools. Een aantal van die voordelen zijn:

• Agentless.
• Playbooks in natuurlijk Engels.
• Playbooks zijn declaratief en kunnen meerdere keren worden toegepast zonder bijwerkingen.
• Open-source en gesponsord door RedHat.

Zoals in de demo zichtbaar, is het super eenvoudig om meerdere servers te configureren en hier op te bouwen, installeren of deployen, zonder kennis te hebben van al deze commando’s. Verder maakt Ansible gebruik van het ‘push’ principe met een connectie via SSH waardoor de follower nodes geen kennis hoeven te hebben van Ansible.

Bronnen

• RedHat. (z.d.). Ansible is Simple IT Automation. Ansible. Geraadpleegd op 6 oktober 2021 van https://www.ansible.com/
• Wikipedia. (2021, 3 oktober). Ansible. Geraadpleegd op 6 oktober 2021 van https://en.wikipedia.org/wiki/Ansible_(software)
• Hummel, G. (2019, 18 september). What is Ansible? Cloud Academy. Geraadpleegd op 6 oktober 2021 van https://cloudacademy.com/blog/what-is-ansible/
• simplilearn. (2019, 27 november). Ansible Full Course | Ansible Tutorial For Beginners | Learn Ansible Step By Step | Simplilearn [Video]. YouTube. Geraadpleegd op 6 oktober 2021 van https://www.youtube.com/watch?v=EcnqJbxBcM0
• Ahmed, R. (2020, 16 september). What Is Ansible? – Configuration Management And Automation With Ansible. Edureka. Geraadpleegd op 6 oktober 2021 van https://www.edureka.co/blog/what-is-ansible/#ansible_in_devops
• Kataria, J. A. A. (z.d.). Managing Docker containers using Ansible. Axelerant. Geraadpleegd op 7 oktober 2021 van https://www.axelerant.com/blog/managing-docker-containers-using-ansible
• Linuxize. (2019, 2 augustus). How to Enable SSH on Ubuntu 18.04. Geraadpleegd op 7 oktober 2021 van https://linuxize.com/post/how-to-enable-ssh-on-ubuntu-18-04/
• Higbee, W. (2020, 13 januari). Getting Started with Ansible [Video]. Pluralsight. Geraadpleegd op 6 oktober 2021 van https://www.pluralsight.com/courses/getting-started-ansible
• Dittrich, D. (z.d.). 2. Ansible and Configuration Management — D2 Ansible playbooks. Davedittrich. Geraadpleegd op 7 oktober 2021 van https://davedittrich.readthedocs.io/projects/ansible-dims-playbooks/en/latest/ansible.html
• Delgehier, C. (2020, 24 april). Why and How We Use Ansible. OpenIO Object Storage. Geraadpleegd op 7 oktober 2021 van https://www.openio.io/blog/why-and-how-we-use-ansible
• Proxy. (2020, 30 juni). Ansible Tower - Geavanceerde IT Automation Proxy Services. Geraadpleegd op 7 oktober 2021 van https://www.proxy.nl/ansible-tower/

Is Linkerd iets voor jou?

Niels Bogers, oktober 2021.

Voor het onderzoek maken we gebruik van de workshop en library onderzoeksruimtes van de ict research methods. Het gebruik van meerdere onderzoeksruimtes zorgt ervoor dat je triangulatie toepast, data verzamelen gebeurt dus op meerdere manieren. We passen de volgende onderzoeksmethoden toe:

• Community research
• Literature study
• Prototyping

We gaan als eerste kijken naar wat Linkerd is en waar het uit bestaat, vervolgens hoe je Linkerd opzet, daarna hoe je Linkerd toevoegt in een bestaande applicatie en tot slot kijken we wat Linkerd toe kan voegen aan een applicatie.

Introductie Linkerd

Linkerd is een service mesh voor Kubernetes. Linkerd maakt het uitvoeren van services veiliger en eenvoudiger door het bieden van runtime debugging, observeerbaarheid, betrouwbaarheid en beveiliging. Linkerd doet dit allemaal zonder aanpassingen te maken aan de al bestaande code.

Een service mesh is een speciale infrastructuurlaag om communicatie tussen services veilig, betrouwbaar en snel te maken (Kunze, 2018a). Waar je normaal de communicatie logica in de services stopt, abstraheert een service mesh die logica met behulp van een proxy. Zo'n proxy draait naast elke service en zo voorkom je aanpassingen aan de code.

Een service mesh omvat meerdere management processen en een set van schaalbare netwerkproxy's die naast de applicatie draaien (Morgan, z.d.). De proxy's vormen de data plane van een service mesh. De management processen vormen de control plane van een service mesh. De architectuur van Linkerd is goed te zien in onderstaande afbeelding.

Opmerking. Overgenomen uit Linkerd vs Istio: Service Mesh Comparison door A. Sahu, 2021 (https://www.infracloud.io/blogs/service-mesh-comparison-istio-vs-linkerd). 2021, Anjul Sahu.

Data plane

In bovenstaande afbeelding is te zien dat de data plane, oftewel de proxy's het verkeer van en naar de services afvangt. Dit gebeurt onder andere om het verkeer van TLS encryptie te voorzien (Fainchtein Buenavida, 2019). Dit gebeurt ook om het gedrag door te geven aan de control plane, deze kan daarmee relevante data tonen in grafieken aan de gebruiker.

Control plane

In bovenstaande afbeelding is te zien waar een deel van de control plane van Linkerd uit bestaat. De control plane heeft echter nog andere componenten die hier niet tussen staan, zoals Prometheus en Grafana.

De control plane heeft controle over de data plane en zorgt ervoor dat de data plane op een gecoördineerde manier kan handelen. Ook zorgt de control plane ervoor dat er een API is waar een gebruiker het gedrag van de data plane kan inspecteren en wijzigen.

Opzetten Linkerd

Om Linkerd te kunnen gebruiken moet je het eerst installeren. Onderstaande instructies geven aan hoe dit moet.

Installatie

Bij deze installatie gaan we er vanuit dat je een werkend kubectl commando hebt, is dit niet zo? Kijk dan hier hoe je dit moet installeren.

De Linkerd CLI installeren kan op met één van de volgende twee opties.

1. Homebrew

   Als je gebruikt maakt van Homebrew dan kan je de CLI met het brew install linkerd commando installeren.

2. Curl

   Als je geen gebruik maakt van Homebrew dan kan je de CLI installeren met behulp van het curl commando. Het installatie commando is: curl -sL run.linkerd.io/install | sh.

   Voeg de CLI toe aan de PATH variabele om verder te kunnen gaan. Het commando hiervoor ziet er als volgt uit: export PATH=$PATH:/c/Users/<USER>/.linkerd2/bin, vervang hierbij <USER> voor de naam van jouw user.

   Dit commando staat ook in de output van het curl commando.

Om te controleren of de installatie succesvol was voer je het linkerd version commando uit, de output toont de versies voor de client en server.

De server version is nu nog unavailable, de volgende stappen lossen dit op.

Voer het volgende commando uit om te controleren of de cluster gereed is om Linkerd te installeren: linkerd check --pre. De output laat zien of de cluster gereed is.

Vervolgens kun je met linkerd install | kubectl apply -f - de control plane installeren. De -f optie geeft aan dat er een naam van een bestand of folder volgt, de - erna laat weten dat het de bestanden pakt die voortkomen uit het linkerd install commando. Dit kan even duren, dus voordat je verder gaat is het aan te raden om te verifiëren dat alles goed ging met het linkerd check commando. De output laat zien of de installatie klaar is.

In Linkerd is het linkerd dashboard commando deprecated. Linkerd raadt daarom aan dat je linkerd viz dashboard gebruikt, zoals te zien in onderstaande afbeelding. Hiervoor is de viz extensie vereist, deze moet je dus installeren.

Met het linkerd viz install | kubectl apply -f - commando voegen we de viz extensie toe. Met het linkerd viz check commando kun je kijken of de installatie van de viz extensie succesvol is verlopen.

Het dashboard openen kan vervolgens met het al eerder genoemde linkerd viz dashboard commando. Het dashboard opent dan automatisch in een nieuw tabblad in de browser.

Toevoegen van Linkerd aan een applicatie

Benodigdheden

De volgende stappen vereisen twee dingen:

1. Een Kubernetes cluster.

   Een makkelijke manier om er één aan te maken is het runnen van een cluster op je lokale machine. Dit kan gemakkelijk met bijvoorbeeld Docker Desktop of k3d.

2. Een valide YAML/JSON bestand.

   Gebruik het curl -sL run.linkerd.io/emojivoto.yml commando om het emojivoto.yml bestand te downloaden, deze kun je gebruiken in de volgende stappen.

Stappen

Om Linkerd ook echt te kunnen gebruiken voeg je het toe aan de applicatie. Onderstaande stappen geven aan hoe dit moet.

1. Pak eerst het YAML/JSON bestand van de applicatie en run het kubectl apply -f <YAML/JSON file> commando.
2. Open een lokale port om de applicatie op te draaien met het kubectl -n <NAMESPACE> port-forward <SERVICE> 8080:80 commando.
3. Voeg Linkerd toe aan de applicatie met het volgende commando:

kubectl get -n <NAMESPACE> deploy -o yaml \
  | linkerd inject - \
  | kubectl apply -f -

Dit commando haalt alle deployments in de meegegeven namespace op, voegt annotaties toe in de Kubernetes deployment bestanden en daarna voert Kubernetes een rolling deploy uit om elke pod zonder downtime bij te werken met de proxies van de data plane.

Linkerd is nu aan de bestaande services toegevoegd!

Toevoegingen van Linkerd

Linkerd voegt een grote reeks aan functionaliteit toe, waaronder (Sahu, 2021):

• Monitoring met Prometheus en Grafana
• Automatic proxy injection
• Load balancing
• High availability mode
• TLS encryptie

De grootste kracht van Linkerd is echter geen van deze functionaliteiten, maar juist dat deze functionaliteiten werken zonder dat Linkerd aanpassingen maakt aan de applicatie. Dit zorgt ervoor dat Linkerd makkelijk in gebruik te nemen is, zelfs voor grootte applicaties.

Het gebruik van Linkerd

Linkerd kan waarde toevoegen aan een applicatie, zeker als de applicatie veel services heeft. Linkerd komt dan ook veel voor in een microservice architectuur. Het is niet noodzakelijk om een microservice architectuur te hebben, het zou bij een monoliet bijvoorbeeld ook waarde kunnen toevoegen (INNOQ, 2021). Het hangt dus echt af van de functionaliteit die de applicatie nodig heeft en wat grootte van de applicatie is.

Applicaties die bijvoorbeeld nog niet in Kubernetes draaien moeten eerst in Kubernetes komen, hier kan veel tijd in gaan zitten. In zo'n geval kan je Linkerd dus beter niet gebruiken (Kunze, 2018b). Ook als je bijvoorbeeld alleen maar monitoring gebruikt dan is het niet verstandig om Linkerd met allemaal 'extra' functionaliteiten toe te voegen die je niet gebruikt, maar kun je beter zelf de monitoring inbouwen.

Conclusie

Is Linkerd iets voor jou? Deze blogpost heeft uitgelegd dat het erg afhangt van de applicatie. Linkerd kan veel functionaliteiten toevoegen, bestaande code hoeft niet aangepast en het is makkelijk te installeren en op te zetten. Het gebruik van Linkerd is daarom vaak handig in grotere applicaties met een microservice architectuur.

Is Linkerd iets voor jou? Naar mijn mening is het altijd verstandig om het gebruik van Linkerd te overwegen als je met een microservice architectuur werkt, zelf zou ik er voor kiezen om het wel te gebruiken tenzij er een goede rede is om het niet te doen.

Toepassen linkerd in Pitstop

Met deze blogpost sluit ik de onderzoeksweek in de minor af en ga door naar de eindopdracht van de coursefase. Dit is een kort DevOps project op basis van Pitstop, een demo applicatie van InfoSupport medewerker Edwin van Wijk. Hierin mag ik de onderzochte technologie ook toepassen. Linkerd toepassen in de pitstop applicatie kan eenvoudig door de installatie en opzet stappen te volgen die ik deze blogpost beschreef. Bij het toevoegen van Linkerd aan de pitstop applicatie gebruik je de .yml bestanden die al in pitstop zitten. In het geval van pitstop gaat het om meerdere .yml bestanden in plaats van één. Het vervangen van kubectl apply -f <YAML/JSON file> voor kubectl apply -f <folder name> is de enige nodige aanpassing, waarbij de <folder name> in dit geval k8s is.

Bronnen

• Bonestroo, W.J., Meesters, M., Niels, R., Schagen, J.D., Henneke, L., Turnhout, K. van (2018). ICT Research Methods. HBO-i Amsterdam. ISBN/EAN: 9990002067426. Geraadpleegd op 7 oktober 2021 van http://www.ictresearchmethods.nl/
• Fainchtein Buenavida, L. (2019, 10 december). Introduction to Service Meshes on Kubernetes. DZone. Geraadpleegd op 7 oktober 2021 van https://dzone.com/articles/introduction-to-service-meshes-on-kubernetes
• INNOQ. (2021, 28 september). Service Mesh Comparison. Geraadpleegd op 7 oktober 2021 van https://servicemesh.es/
• Kunze, T. (2018a, december 11). What is a Service Mesh?. Glasnostic. Geraadpleegd op 8 oktober 2021 van https://glasnostic.com/blog/what-is-a-service-mesh-istio-linkerd-envoy-consul
• Kunze, T. (2018b, 18 december). Should I Use a Service Mesh?. Glasnostic. Geraadpleegd op 7 oktober 2021 van https://glasnostic.com/blog/should-i-use-a-service-mesh
• Morgan, W. (z.d.). The Service Mesh: What Every Engineer Needs to Know about the World’s Most Over-Hyped Technology. Buoyant. Geraadpleegd op 6 oktober 2021 van https://buoyant.io/service-mesh-manifesto/
• Sahu, A. (2021, 9 maart). Linkerd vs Istio: Service Mesh Comparison. InfraCloud. Geraadpleegd op 6 oktober 2021 van https://www.infracloud.io/blogs/service-mesh-comparison-istio-vs-linkerd/

Infrastructure as Code in Microsoft Azure met Terraform

Tristan Boland, October 2021.

Deze blogpost introduceert de beginselen van Infrastructure as Code (IaC) in Microsoft Azure Services en ook de tool Terraform.

De post geeft een korte indruk van enkele zaken, allereerst een korte theoretische introductie van IaC. Daarna duiken we in de voordelen van IaC vergeleken met de "gebruikelijke" manier om infrastructure te beheren in Azure. Tot slot do ik een stap voor stap implementatie van IaC in de Microsoft Azure stack met de tool Terraform, via lab onderzoek (Bonestroo et al., 2018).

Kennis maken met IaC

Om te beginnen: Infrastructure as Code is het proces van het vervangen van handmatige stappen voor het maken en beheren van infrastructure met regels code (Workfall, 2021). Deze noemt met vaak configuratiebestanden of resources. Deze resources kunnen elk stuk infrastructure in a bepaalde omgeving maken, bijvoorbeeld een virtuele machine, een database, of — in de context van Azure — een logic app of service bus.

Infrastructure as code workflow (DigitalOcean, 2021)

Gebruik en voordelen van IaC

Er zijn een aantal voordelen van het gebruik van IaC, waarvan de voornaamste is dat het een efficiente en consistente manier is om infrastructuur te definieren en beheren.

Versiebeheer

Het definieren van infrastructuur resources maakt het mogelijk om wijzigingen te en toevoegingen aan de infrastructuur bij te houden in versiebeheer. Het gevolg is een historie van wijzigingen in je infrastructuur, waarnaar je makkelijk een rollback kunt doen in geval van een fout of niet werkend systeem.

Ook is het mogelijk om de wijzigingen in je infrastructuur te inspecteren en controleren voordat je daadwerkelijke oplevert.

Documentatie

Deze bestanden kunnen ook dienen als documentatie, aangezien de bestanden een specificatie zijn van de state (toestand) en opmaak van de services op een leesbare manier.

Snelheid

Ook is het op deze manier specificeren van je infrastructuur een stuk sneller. Vooral als je te maken hebt met een zeer uitgebreide infrastructuur, is het simpelweg niet mogelijk om alles te behren via een grafische user interface. Niet DevOps teams hebben het nog zwaarder te verduren, aangezien developers moeten wachten op een apart ops team om de benodigde infrastructure in de lucht te brengen (SDxCentral, 2021).

Je kunt makkelijk delen van IaC bestanden hergebruiken om specifieke services op te schalen.

Automatisering

Bovendien kunnen tools zoals Terraformje in staat stellen jr process te automatiseren. Je kan een IaC configuratie wijzigen of toevoegen. Daarna kun je de deployment van de wijzingen integreren in je CI/CD pipeline om deze naar een cloud provider naar keuze op te leveren.

Best practices with IaC

Voordat je IaC toepast is het goed om te een paar best practices te kennen om je aan te houden. Ik heb enkele van deze practices hieronder opgesoms, welke ik het meest waardevol vindt.

Documenting

When using infrastructure as code your configuration files will essentially be your documentation (Chan, 2021). This doesn't mean you shouldn't write any documentation at all!

In complexe landschappen kunnen diagrammen heel waardevol zijn. In sommige gevallen is een snelle blik op een overzicht / diagram meer waard dan de gehele structuur van de configuratie file te bestuderen.

Keep it simple, keep it modular

Het is een best practice om de configuratiebestanden simpel te houden en makkelijk te lezen. Op die manier kunnen andere developers makkelijk up to speed komen met de infrastructuur configuratie.

Dit kun je bijvoorbeeld doen door te modulatiseren. Als je de configuratie modulair houdt, dan kun je elementen hergebruiken, wat voor een consistente file structure zorgt (Xenonstack, 2021).

Mutable of immutable

Een mutable infrastructure betekent dat je wijzigingen kunt toepassen op je infrastructure terwijl deze al up and running is. Het hanteren van mutable infrastructure zorgt ervoor dat individuele wijzigingen aan je cluster kunnen zorgen voor configuration drift, waarbij een cluster stapsgewijs steeds meer afwijkt over de tijd, als gevolg vn de handmatige wijzigingen (Pelletier, 2020).

Sommigen argumenteren dat een betere manier om met wijzigingen om te gaan is met Immutable Infrastructure. Dit betekent de infrastructure die runt weggooien en deze volledig vervangen als je een wijziging deployed. Zo sta je toe om vorige configurations op te slaan als versies, en makkelijk opnieuw te deployen op basis van een versie van de infrastructuur (Vasiljevic, 2021).

Mutable vs immutable (Vasiljevic, 2021)

Implementing IaC

Er is een heel scale van tools die je kunt gebruiken voor IaC. In dit geval focussen we op Terraform. Aangezien je Terraform kunt integreren met een veelheid aan cloud service providers.

Overzicht van de workflow van Terraform (Hashicorp, 2021)

Implementing IaC with Terraform

Terraform gebruikt .tf bestanden om je infrastructure configuraties in op te slaan. De syntax lijkt op Yaml and JSON. Als gewenst kun je ook een .tf.json file extensie gebruiken, die je toestaat om JSON te schrijven.

Om te beginnen met het implementern van IaC, zal ik eerst een configuratie voor een lokale Docker container maken om bekent te raken met de syntax en verschillende onderdelen van Terraform.

Ik heb een .tf configuratie bestand gemaakt met instructies om Nginx te runnen op een lokale Docker container:

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = ">= 2.13.0"
    }
  }
}

provider "docker" {
  host    = "npipe:////.//pipe//docker_engine"
}

resource "docker_image" "nginx" {
  name         = "nginx:latest"
  keep_locally = false
}

resource "docker_container" "nginx" {
  image = docker_image.nginx.latest
  name  = "NginxUsingTerraform"
  ports {
    internal = 80
    external = 8000
  }
}

Dit bestand bestaat uit het volgende:

• Terraform blok met Terraform settings.
• Een lijst van vereiste providers binnen het Terraform blok. Dit lijkt op een dependency die is vereist om de infrastructuur te creeren.
• Een provider, die in dit geval ons doorverwijst naar onze Docker Engine die de infrastructure aanmaakt.
• Een lijst van resources. Dit zijn de resources om aan te maken. In dit geval is er een Nginx image, en een Nginx container waarop de image gedeployed zal worden.

Terraform commando's

Terraform ondersteunt de volgende basic commando's:

• Om Terraform te initialiseren en de vereiste dependencies te downloaden gebruik terraform init.
• Om de configuratie te valideren gebruik je terraform validate.
• To see a list of changes to be deployed use terraform plan.
• To apply changes to your infrastructure use terraform apply.
• To stop your running infrastructure use terraform destroy.

TODO: Rest vertalen Using the init and apply commands the infrastructure is deployed to a local Docker instance. A list of changes is shown and Terraform asks for confirmation before deploying.

After a short while you will see the specified Nginx container running in your local Docker instance.

Scaling up

Say you want to add another Nginx container to your infrastructure. Since the image and Docker provider are listed above for the first resource. Adding a second container is as easy as adding a second resource to the configuration file.

Adding the following resource to the file creates a second Docker container running Nginx in Docker.

resource "docker_container" "nginx_clone" {
  image = docker_image.nginx.latest
  name  = "NginxUsingTerraformClone"
  ports {
    internal = 81
    external = 8001
  }
}

Both resources running in a Docker container

Implementing Terraform on Microsoft Azure

Terraform can communicate with a multitude of cloud services. I will use Azure for this example.

A prerequisite to working with Terraform in Azure is being logged in to your Azure account using the Azure cli.

To get started you can want to create a resource group and storage account. This resource group will contain all our resources.

I created the resource group and storage account using the following configuration:

resource "azurerm_resource_group" "rg" {
  name     = var.resource_group_name
  location = var.location
}

resource "azurerm_storage_account" "storageaccount" {
  name                     = "tbterraformstorageac"
  resource_group_name      = var.resource_group_name
  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

You might notice var.[name] items in this example, these are variables.

Variables

Terraform configuration files support variables as well. For example the name of the resource group I created will be re-used in future configuration files. To add variables you can create a new configuration file which can contain the following:

variable "resource_group" {
  default = "TerraformResourceGroup"
}
variable "location" {
  default = "westeurope"
}

Adding a resource to Azure

Next I will create a feature branch, on this branch I will make some changes to our infrastructure. I will be adding a MSSQL Database to azure.

To add cloud specific resources there are a multitude of templates available in the Terraform registry to get started. As there are way too many configuration options for each resource to remember!

I added the following file to create a database server and the MSSQL instance:

resource "azurerm_mssql_server" "tbdatabaseserver" {
  name                         = "tbdatabaseserver"
  resource_group_name          = var.resource_group_name
  location                     = var.location
  version                      = "12.0"
  administrator_login          = "tb4dm1n!"
  administrator_login_password = "SuperSecurePass123!"
}

resource "azurerm_mssql_database" "tbsqldatabase" {
  name           = "tbsqldatabase"
  server_id      = azurerm_mssql_server.tbdatabaseserver.id
  collation      = "SQL_Latin1_General_CP1_CI_AS"
  license_type   = "LicenseIncluded"
  max_size_gb    = 4
  read_scale     = true
  sku_name       = "BC_Gen5_2"
  zone_redundant = true

  extended_auditing_policy {
    storage_endpoint                        = azurerm_storage_account.storageaccount.primary_blob_endpoint
    storage_account_access_key              = azurerm_storage_account.storageaccount.primary_access_key
    storage_account_access_key_is_secondary = true
    retention_in_days                       = 6
  }
}

You can apply these changes directly from the command line using the apply command. But in most cases, you won't be working on your own. Terraform changes can be tracked by your version control system, and thus your changes can be monitored when making a pull request. There will be more info about this below.

Integrating Terraform into your pipeline

When your Terraform infrastructure is added to your version control system you are able to integrate it into your build pipeline. This allows you to see the changes Terraform is about to make to your infrastructure when creating pull requests.

Adding Terraform support is as easy as adding a Terraform extension to Azure DevOps.

You can then add the terraform init, ... validate, ... plan, ... apply commands to your pipeline stages. Allowing you to validate the changes you are going to make to your infrastructure. Show the changes using the output of plan, to eventually merge the changes kicking off an apply pipeline.

Unfortunately I am not able to demonstrate this due to missing privileges in Azure. If you do want to try this for yourself I would highly recommend reading the following blogposts:

• Terraforming from zero to pipelines as code with Azure DevOps. Thomas Thornton, 2021, about creating an Azure pipeline with Terraform integration.

• Azure DevOps #1 - Terraform Plan as a PR Comment – Kamil Wiecek, 2021 About a custom way to add Terraform comments to your PR's.

In summary

When starting a new project, or when currently working on a project. I would highly recommend to implement IaC as it simplifies creating and managing infrastructure for your project. It allows anyone to create infrastructure without having to navigate a user interface. They can easily get up to date on the infrastructure landscape since the configuration files are readable and serve as documentation.

Versioning of infrastructure is easily done because the infrastructure configuration is checked in to your version control system. Which also allows the ability to review changes before deploying.

Using a tool like Terraform you are able to easily apply your changes to a multitude of cloud services.

Sources

• Workfall. (2021, February 26). How to manage infrastructure as code (IaC) with Terraform on AWS? Medium. Opgehaald, october 2021 van https://medium.com/workfall/how-to-manage-infrastructure-as-code-iac-with-terraform-on-aws-1fa6cd6bccfe
• Hashicorp. (2021). Terraform overview. Retrieved October 2021, from https://www.terraform.io
• Bonestroo, W.J., Meesters, M., Niels, R., Schagen, J.D., Henneke, L., Turnhout, K. van (2018). ICT Research Methods. HBO-i, Amsterdam. ISBN/EAN: 9990002067426. Retrieved October 2021, from http://www.ictresearchmethods.nl
• Chan, M. (2021, January 26). Infrastructure as Code: 6 best practices to get the most out of IaC. Thorn Technologies. Retrieved October 2021, from https://www.thorntech.com/infrastructure-as-code-best-practices
• Pelletier, J. (2021, May 20). Configuration Drift in Kubernetes - What is it and Why it Matters. Fairwinds. Retrieved October 2021, from https://www.fairwinds.com/blog/configuration-drift-kubernetes
• Vasiljevic, R. (2021, June 4). IaC Benefits, Challenges & Best Practices. SuperAdmins. https://superadmins.com/infrastructure-as-code-demystified-iac-benefits-challenges-best-practices/#IaC_Best_Practices_According_to_SuperAdmins
• Terraform. (n.d.). Azurerm_mssql_database. Terraform.Io. Retrieved 6 October 2021, from https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/mssql_database
• Thornton, T. (2020, October 27). Validating Terraform Code During A Pull Request In Azure DevOps. Thomas Thornton. Retrieved October 2021, from https://thomasthornton.cloud/2020/07/29/validating-terraform-code-during-a-pull-request-in-azure-devops
• Kamil Wiecek (2021). Terraform plan as a PR comment. Azure DevOps #1. Retrieved October 2021, from https://www.kamilwiecek.com/blog/azure-dev-sec-platform-ops
• Thornton, T. (2020b, December 4). Terraforming from zero to pipelines as code with Azure DevOps. Thomas Thornton. Retrieved October 2021, from https://thomasthornton.cloud/2020/11/28/terraforming-from-zero-to-pipelines-as-code-with-azure-devops
• Xenonstack. (2021). Infrastructure as Code Tools and Best Practices. Retrieved October 2021, from https://www.xenonstack.com/blog/what-is-infrastructure-as-code
• SDxCentral. (2021, 19 maart). Server Resolution Error 1001. Retrieved October 2021, from https://www.sdxcentral.com/articles/sponsored/implementing-infrastructure-as-code-for-cloud-speed-and-agility/2021/06/

SpecFlow in een DevOps project

Ivo Breukers, oktober 2021.

Het doel van dit onderzoek is uitsluitsel geven of SpecFlow gebruikt zal worden in het beroepsproduct van de minor DevOps. De deelvragen beantwoorden de hoofdvraag van dit onderzoek. De deelvragen zijn:

• 1. Wat is SpecFlow?
• 2. Hoe past SpecFlow binnen BDD?
• 3. Hoe werkt SpecFlow in de praktijk?

Ik onderzoek n.a.v. de eerste twee deelvragen middels literature study uit de ICT Research Methods van Bonestroo et al. (2018), de gekozen technologie respectievelijk hoe deze binnen BDD past. In de laatste deelvraag toets ik de technologie in de praktijk, middels de onderzoeksmethode prototype. De drie hierop volgende hoofdstukken beantwoorden de deelvragen in de volgorde zoals hierboven staat. Tot slot beantwoordt de conclusie de hoofdvraag van dit blog.

1. SpecFlow

SpecFlow is een opensource framework dat een testautomatiseringsoplossing biedt voor .NET, gebaseerd op het BDD-paradigma. SpecFlow definieert, beheert en voert voor mensen leesbare acceptatietests uit in .NET-projecten (SpecFlow, z.d.-a). Eenvoudig gezegd is SpecFlow Cucumber voor .NET (CODEDEC, z.d.).

SpecFlow biedt een mechanisme om specificatie om te zetten in uitvoerbare code. Dit kan je vervolgens gebruiken om geautomatiseerde tests te maken, die je kan uitvoeren met applicatie code om te controleren of deze het gedrag vertoont zoals beschreven in de specificaties (Dijkstra, 2020).

SpecFlow tests schrijf je met behulp van Gherkin, waarmee je test cases kunt schrijven in natuurlijke talen. SpecFlow gebruikt de officiële Gherkin parser, die meer dan 70 talen ondersteunt. Met SpecFlow koppel je deze tests met zogenaamde bindings aan de applicatiecode, waarna je deze tests kunt uitvoeren met behulp van een test framework naar keuze (SpecFlow, z.d.-a). SpecFlow zet de specificaties die zijn geschreven in de Gherkin Given / When / Then syntax, als scenario's in feature files om in uitvoerbare code, ook wel 'step definitions' genoemd (Dijkstra, 2020).

Nadat deze stappen zijn omgezet in uitvoerbare code, houdt de verantwoordelijkheid van SpecFlow op. Om de testautomatisering verder te implementeren, zodat deze daadwerkelijk communiceert met de te testen applicatie, moet je een andere tool toevoegen aan de testautomatseringsoplossing. Enkele tools die vaak in combinatie met SpecFlow worden gebruikt om een testautomatiserings framework te vormen zijn NUnit, MSTest en xUnit (Dijkstra, 2020).

Het SpecFlow ecosysteem

Dijkstra (2020) schrijft dat naast het kernproject ook enkele tools beschikbaar zijn van SpecFlow, die gezamenlijk bekend staan als SpecFlow+. Onderdeel van deze collectie zijn:

• SpecFlow+ Runner, een test runner specifiek geschreven voor SpecFlow
• SpecFlow+ Excel, hiermee kan de kracht van Microsoft Excel gebruikt worden om functies en scenario's te maken.
• SpecFlow+ LivingDoc, voor het maken van documentatie van feature files

2. SpecFlow in BDD

De YouTube video 'Getting Started with SpecFlow' (2020) legt uit dat behavior-driven development (BDD) bestaat uit vier fasen:

1. Illustration/discovery fase
2. Formulation fase
3. Automation fase
4. Validation fase

Dijkstra (2020) schrijft dat een van de belangrijkste doelen van BDD is om een gedeeld begrip te creëren van hoe een applicatie zich zou moeten gedragen, door discussie te vergemakkelijken en met concrete voorbeelden te komen. Dit wordt uitgedrukt in een Domain Specific Language (DSL), met behulp van de Given / When / Then syntax, dat bekend staat als Gherkin. Het andere onderdeel van BDD houdt zich bezig met het omzetten van deze specificaties in geautomatiseerde acceptatietests, en dat is waar SpecFlow in het spel komt.

SpecFlow kan je (normaliter) alleen gebruiken in de automation fase, zoals onderstaand figuur toont. SpecFlow is een tool die BDD ondersteunt, dus door alleen SpecFlow te gebruiken ben je niet automatisch BDD aan het toepassen. Het is mogelijk BDD te doen zonder SpecFlow en het is ook mogelijk SpecFlow te gebruiken zonder BDD (SpecFlow, 2020).

Bron: SpecFlow (2020)

3. SpecFlow in de praktijk

Stap nul, alvorens we beginnen met de realisatie van het prototype, is het installeren van een SpecFlow plugin voor de IDE. SpecFlow biedt een extensie voor Visual Studio en een plugin voor JetBrains Rider. Deze zijn eenvoudig te installeren binnen de gekozen IDE.

Dit prototype gebruikt JetBrains Rider, in voorbeelden zal deze IDE ook zichtbaar zijn. De stappen voor Visual Studio zullen vrij hetzelfde zijn, het is dus mogelijk om de stappen binnen Visual Studio te volgen.

De eerste stap is het aanmaken van een solution met een "Class library", beide genaamd SpecFlowCalculator. Dit prototype gebruikt SDK: 5.0, taal: C# en framework: net5.0, zoals in het onderstaand figuur zichtbaar is.

Na het aanmaken van de solution en het project hernoemen we Class1.cs naar Calculator.cs en vervangen zijn content met de volgende code:

using System;

namespace SpecFlowCalculator
{
    public class Calculator
    {
        public int FirstNumber { get; set; }
        public int SecondNumber { get; set; }

        public int Add()
        {
            throw new NotImplementedException();
        }
    }
}

Vervolgens maken we een nieuw project aan binnen de solution. Dit project is van het type SpecFlow Project, heet SpecFlowCalculator.Specs , maakt gebruik van het net5.0 framework en gebruikt xUnit als test framework, zie de onderstaande afbeelding voor de uitwerking.

Na het aanmaken van het SpecFlow Project voegen we de class library toe als dependency, binnen JetBrains Rider kan het op de onderstaande manier.

Na het toevoegen van de dependency maken we een feature file aan in de map Features, dit bestand noemen we Calculator.feature.

Deze feature file vullen we met een scenario in Gherkin, dit scenario neemt twee getallen, geeft aan dat ze bij elkaar opgeteld moet worden en geeft een verwacht resultaat.

Feature: Calculator
Simple calculator for adding **two** numbers

@mytag
Scenario: Add two numbers
  Given the first number is 50
  And the second number is 70
  When the two numbers are added
  Then the result should be 120

Na het aanmaken van de feature file en het schrijven van het eerste scenario is het tijd om de step definitions aan te maken. We plaatsen dit bestand in de Steps folder, noemen het CalculatorStepDefinitions.cs en vullen het met de step definitions, gebaseerd op de bovenstaande Gherkin code.

Binnen deze klasse maken we een instantie van Calculator en een variabele _result aan. Tot slot implementeren we de step definitions, het resultaat is:

using TechTalk.SpecFlow;
using Xunit;

namespace SpecFlowCalculator.Specs.Steps
{
    [Binding]
    public sealed class CalculatorStepDefinitions
    {
        private readonly ScenarioContext _scenarioContext;
        private readonly Calculator _calculator = new();
        private int _result;

        public CalculatorStepDefinitions(ScenarioContext scenarioContext)
        {
            _scenarioContext = scenarioContext;
        }

        [Given("the first number is (.*)")]
        public void GivenTheFirstNumberIs(int number)
        {
            _calculator.FirstNumber = number;
        }

        [Given("the second number is (.*)")]
        public void GivenTheSecondNumberIs(int number)
        {
            _calculator.SecondNumber = number;
        }

        [When("the two numbers are added")]
        public void WhenTheTwoNumbersAreAdded()
        {
            _result = _calculator.Add();
        }

        [Then("the result should be (.*)")]
        public void ThenTheResultShouldBe(int result)
        {
            Assert.Equal(result, _result);
        }
    }
}

Na het implementeren van de step definitions kunnen we de tests draaien. Het resultaat is falende tests, met als melding dat er een NotImplementedException optreedt, dit komt omdat de Add methode van Calculator nog niet geïmplementeerd is.

Nu is het tijd om de Add methode van Calculator te implementeren op de volgende manier:

public int Add()
{
    return FirstNumber + SecondNumber;
}

Na deze implementatie runnen we de tests opnieuw, met als resultaat dat alle steps slagen.

Bij de realisatie is gebruik gemaakt van: SpecFlow (z.d.-b).

Living Documentation

Door gebruik te maken van de SpecFlow+ LivingDoc tool kan er living documentation gegenereerd van alle test resultaten, zodat deze gemakkelijk gedeeld kunnen worden met het team.

De LivingDoc CLI tool kan je installeren met het volgende commando:

dotnet tool install --global SpecFlow.Plus.LivingDoc.CLI

Na de installatie moet je naar de output directory van het SpecFlow project navigeren. Hier kan je komen door het volgende commando uit te voeren, vanuit de root van deze repository.:

cd SpecFlowCalculator/SpecFlowCalculator.Specs/bin/Debug/net5.0/

Binnen deze map kan je living documentation genereren met het onderstaande commando:

livingdoc test-assembly SpecFlowCalculator.Specs.dll -t TestExecution.json

Dit genereert een HTML bestand met alle scenario's en resultaten op de volgende locatie:

SpecFlowCalculator/SpecFlowCalculator.Specs/bin/Debug/net5.0/LivingDoc.html

Conclusie

SpecFlow is een opensource framework dat je kan gebruiken om voor mensen leesbare acceptatietests te definiëren, beheren en automatisch uit te voeren in .NET-projecten. SpecFlow zet specificaties, scenario's in feature files, die zijn geschreven in Gherkin om in uitvoerbare code, ook wel step definitions genoemd.

SpecFlow is een tool die BDD ondersteunt, op zichzelf is het geen BDD. Wanneer je SpecFlow binnen BDD gebruikt komt het aanbodt in de automation fase, de derde van de vier fasen binnen BDD.

Het gebruik van SpecFlow is in de praktijk prettig, dit komt doordat de documentatie voor het framework duidelijk en uitgebreid is. Ook zijn er verschillende guides en voorbeeldprojecten te vinden. De extensie die SpecFlow biedt draagt eraan bij dat dat SpecFlow prettig in gebruik is. SpecFlow zelf biedt ook nog aanvullende SpecFlow+ tools die het werken met SpecFlow bevorderen.

De eindconclusie is dat SpecFlow een ideale tool is voor een DevOps project dat gebruik maakt van services die je realiseert in .NET en volgens behavior-driven development.

Bronnen

• Bonestroo, W. J., Meesters, M., Niels, R., Schagen, J. D., Henneke, L., & Turnhout, K. (2018). ICT Research Methods. HBO-i, Amsterdam. Geraadpleegd oktober 2021 van http://www.ictresearchmethods.nl/
• CODEDEC. (z.d.). What is SpecFlow. Geraadpleegd op 6 oktober 2021 van https://codedec.com/tutorials/what-is-specflow/
• Dijkstra, B. (2020, 6 april). BDD, SpecFlow and The SpecFlow Ecosystem. Geraadpleegd op 6 oktober 2021 van https://blog.testproject.io/2019/10/08/bdd-and-the-specflow-ecosystem/
• SpecFlow. (2020, 11 september). Getting Started with SpecFlow [Videobestand]. Geraadpleegd van https://www.youtube.com/watch?v=HpRzI0C-x-8
• SpecFlow. (z.d.-a). Welcome to SpecFlow’s documentation! Geraadpleegd op 6 oktober 2021 van https://docs.specflow.org/projects/specflow/en/latest/
• SpecFlow. (z.d.-b). *Welcome to the Step-By-Step Getting Started Guide!() Geraadpleegd op 6 oktober 2021 van https://docs.specflow.org/projects/getting-started/en/latest/index.html

Een zwerm van Docker nodes

Mark Brouwer, oktober 2021.

Dit onderzoek heeft als doel kennis van deze technologie op te doen zodat het eventueel gebruikt kan worden in een klein DevOps project. In deze context zou Docker Swarm toegepast kunnen worden om een microservice architectuur te deployen.

Eerst een uitleg wat Docker Swarm nou precies is en waar een cluster uit bestaat. Daarna volgt een hands-on onderdeel met twee verschillende configuraties van een Swarm cluster. Ten slotte een vergelijking van Docker Swarm op een aantal onderwerpen en beschrijving in welke situaties je het beste Docker Swarm kunt toepassen.

Wat is Docker Swarm?

Docker Swarm (Docker, z.d.) is een container orchestration tool waarmee een gebruiker meerdere containers over een aantal verschillende host machines kan deployen (sumo logic, z.d.). Deze fysieke of virtuele nodes vormen samen een cluster vormen. Binnen dit cluster kun je nog steeds je Docker commando’s uitvoeren. Het enige verschil is nu dat deze commando’s worden uitgevoerd door de verschillende nodes in je cluster.

Docker Swarm, of Swarm Mode, draait op de swarming toolkit ‘Swarmkit’. In vroegere versies van Docker was het optioneel om deze software toe te voegen aan je Docker installatie, maar vanaf Docker 1.12 zit Swarmkit standaard bij een Docker installatie ingebakken (Poulton, 2018).

Nodes

Een swarm bestaat uit een groep van machines die samen gebundeld zijn tot een cluster. Als een nieuwe machine aan dit cluster wordt toegevoegd, wordt het een node in de swarm. Het is in principe niets anders dan een Docker node, het enige verschil is dat je vaak bij development te maken hebt met je eigen lokale node. Dit is de machine waar je op werkt. Echter zie je al gauw bij productie swarm deployments dat je te maken hebt met meerdere Docker nodes die zijn verdeeld over meerdere fysieke en virtuele (cloud) machines (Docker, z.d.).

Zoals in Afbeelding 1 staat afgebeeld, bestaat een Swarm uit verschillende soorten groepen en wordt er onderscheid gemaakt tussen verschillende soorten nodes. Hoewel het diagram maar twee soorten nodes laat zien, bestaan er drie typen nodes die ieder een eigen rol spelen in het swarm ecosysteem.

Afbeelding 1. Globaal overzicht van een Docker Swarm.

Manager nodes zijn nodes die voor het cluster management zorgen. Ze zorgen ervoor dat taken worden toegewezen aan worker nodes en dat de swarm zich in de gewenste staat bevindt. Nigel Poulton (2018) stelt dat Docker een minimaal aantal van drie en een maximaal aantal van zeven manager nodes aanbeveelt. Minder dan dit aantal kan nadelig werken op de availability van je cluster en meer dan dit aantal kan voor onnodige complexiteit zorgen. Een van de manager nodes wordt geclassificeerd als de leader node. De leader node maakt alle beslissingen die betrekking hebben tot swarm management en taakverdeling. Als de leader uitvalt, wordt er door middel van het Raft consensus algoritme een nieuwe leader gekozen.

Worker nodes zijn nodes die de de toegewezen taken van de manager nodes uitvoeren. Docker (z.d.) stelt dat de manager nodes standaard ook worker nodes zijn, maar het is eventueel zo te configureren dat deze twee takenpakketten van elkaar worden gescheiden en dat manager nodes exclusief management taken uitvoeren. Gedurende het uitvoeren van de taken wordt de status van de worker node bijgehouden door een agent die bij de worker node draait. Deze agent rapporteert de status van de node en de uit te voeren taken aan de manager nodes zodat deze de gewenste staat van iedere worker node kan bijhouden.

Services

Een Service is de definitie van een taak die wordt uitgevoerd op een manager of een worker node. Docker Swarm hanteert twee soorten services:

• Replicated services: Swarm mode replicated services functioneert op een manier waarop jij als gebruiker aangeeft hoeveel replica’s van een taak uitgevoerd worden. De manager distribueert de replica’s over de beschikbare nodes op basis van de schaal die je hebt aangegeven. Je wilt bijvoorbeeld vier replica’s van een front-end applicatie runnen.
• Global services: Global services funtioneert op een manier waarop de swarm manager de taak op elk van de beschikbare nodes dat aan opgegeven service constraints en resource requirements voldoet.

Hoe werkt Docker Swarm?

Om de werking van docker swarm op een simpele manier toe te lichten, heb ik drie virtuele machines opgezet: manager, worker1 en worker2. Alle drie machines draaien versie 20.10.9. van de Docker engine.

Een swarm configureren

Om een swarm te configureren, voert de eerste node het commando docker swarm init uit. Afbeelding 2 toont dat het commando een nieuwe swarm aanmaakt en dat de node een manager wordt.

Afbeelding 2. Aanmaken van een docker swarm.

Bovenstaand docker swarm join commando voer je nu uit op de twee worker machines. Zoals in Afbeelding 3 is te zien, worden deze machines nu nodes in de swarm.

Afbeelding 3. De twee worker nodes joinen de swarm.

Je kunt dit controleren door bij de manager docker node ls uit te voeren. In Afbeelding 4 zie je dat het een lijst van nodes geeft, waarbij het zichzelf als manager ziet en de twee toegevoegde nodes in het lijstje weergeeft.

Afbeelding 4. De huidige nodes in het cluster.

Een service deployen in Docker Swarm

Om een replicated service te deployen in de swarm, voer je het commando docker service create uit. Zie onderstaand commando om drie replica’s van een nginx service te maken en deze te publishen op poort 8080.

docker service create --name webapp \
                        --replicas 3 \
                        --publish published=8080,target=80 \
                        nginx

Afbeelding 5 toont drie replica’s van de nginx service gedeployed op het cluster.

Afbeelding 5. Het aanmaken van drie replica’s van een nginx service.

Meerdere services deployen met Docker stack

Poulton (2018) stelt dat het mogelijk is om op een meer declaratieve manier je services in één keer te deployen op de docker swarm. Hiervoor gebruik je stackfiles. Dit zijn niet meer dan docker-compose bestanden met meer informatie om een deployment uit te voeren op een cluster. Voor deze blog heb ik een simplistische NodeJS Express applicatie gebouwd die een aantal resultaten van een MongoDB database teruggeeft. De applicatie vind je hier te vinden, en heeft de volgende structuur:

Als eerst schrijf je een docker-compose.yml die geschikt is om een docker stack deploy actie uit te voeren. Dit betekent dat de compose file versie 3+ moet zijn (Poulton, 2018).

Ook moet je voor iedere service een deploy onderdeel definiëren. In dit onderdeel geef je aan of je de service global of replicated wilt deployen en hoeveel replica’s je op de nodes moeten komen. Je kunt eigen update- en/of restart configuratie aangeven om in te spelen op wijzigingen in het cluster en hoe je om wilt gaan met crashes. Binnen het deploy blok kun je dus in feite je gewenste state aangeven.

Voor de sample app is het onderstaande stackfile opgesteld. De webapi service deployed de service nu in replicated mode met drie verschillende replica's en de mongo service deployed Docker enkel op een manager node.

version: '3'
services:
  webapi:
    image: 127.0.0.1:5000/swarm-demo
    build: .
    ports:
      - "3000:3000"
    networks:
      - swarm-app
    deploy:
      mode: replicated
      replicas: 2
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s
    depends_on: 
      - db
  db:
    image: mongo
    ports:
    - "27017"
    volumes:
    - mongodata:/data/db
    restart: "always"
    deploy:
      placement:
        constraints: [node.role == manager]
    networks:
    - swarm-app
volumes:
  mongodata: {}
      
networks:
  swarm-app:

Om deze applicatie in de docker swarm te deployen, voer je het commando docker stack deploy --with-registry-auth --compose-file docker-compose.yml swarm-demo uit. Afbeelding 6 toont de gedefinieerde services met bijbehorende aantal replica’s.

Afbeelding 6. Het deployen van een stackfile in de docker swarm.

Het resultaat van de Express applicatie te zien (zie Afbeelding 7) door naar poort 3000 te navigeren.

Afbeelding 7. Resultaat van de Express web applicatie.

Docker Swarm vs. Kubernetes

Docker Swarm en Kubernetes zijn beiden container orchestration software. Waarin verschilt Docker Swarm van Kubernetes en waarin komt het overeen? Hieronder staan de belangrijkste punten op een rijtje.

• Installatie en gebruik — Docker Swarm maakt standaard deel uit van de Docker Engine, waardoor het bij een Docker installatie inbegrepen is. Kubernetes moet apart worden geïnstalleerd en geconfigureerd, dit wordt door sommigen als complex ervaren (Drewel, 2021).
• Leercurve — Met kennis van het gebruik van Docker is de leercurve vrij vlak voor het gebruik van Docker Swarm. Kubernetes daarentegen is een stuk uitgebreider dan Docker Swarm, hierdoor is de leercurve ook stijler. De gebruiker moet bijvoorbeeld leren om de kubectl CLI te gebruiken. Docker swarm kan makkelijk worden gebruikt door gebruikers die kennis hebben van de Docker CLI.
• Scalability — Zowel Kubernetes en Docker Swarm maken gebruik van automatisch opschalen van services (IBM, 2021). De manier waarop ze dit doen verschilt wel. Omdat Kubernetes uitgebreider is, duurt het opschalen langer dan bij Docker Swarm (Sengupta, 2020). Hierdoor is Docker Swarm geschikter voor on-demand scaling.
• High Availability — Het grootste verschil in HA is te vinden in de manier waarop het cluster wordt beheerd. Docker Swarm garandeert HA door op manager node niveau service replication uit te voeren. Kubernetes bevat een geavanceerder controle (control plane) systeem waarbij de Control Plane ‘unhealthy’ nodes direct aanpakt (Rosen, 2020).
• Monitoring — Kubernetes biedt veel meer mogelijkheden voor third-party monitoring software integration zoals Prometheus, Grafana en InfluxDB. Docker Swarm kan op een aantal manieren gemonitored worden, maar over het algemeen ervaart men dit als complex door de vele cross-node objecten en services.

Is Docker Swarm de orchestration tool voor jou?

Zoals in deze blog is aangetoond, kan je op een gemakkelijke manier een Docker Swarm cluster configuren en gebruiken. Een cluster bevat een simpele begrijpbare structuur met manager en worker nodes. Het kent veel overeenkomsten, maar ook verschillen met grotere orchestration tools zoals Kubernetes, met name in onderliggende technologiëen, maar ook in de mogelijkheden van bijvoorbeeld monitoring en het gebruik hiervan.

Bij het kiezen voor een orchestration tool, moet je bepaalde factoren afwegen. Het moet aansluiten op je behoeften. Is je microservice architectuur van kleinere schaal, wil je binnen het domein van Docker blijven werken, heb je geen extra lagen van indirectie nodig en wil je snel on-demand kunnen schalen? Dan is Docker Swarm de tool voor jou.

Bronnen

• Docker. (z.d.). Empowering App Development for Developers. Geraadpleegd op 6 oktober 2021 van https://www.docker.com
• Docker. (z.d.). Deploy a stack to a swarm. Docker Documentation. Geraadpleegd op 6 oktober 2021 van https://docs.docker.com/engine/swarm/stack-deploy
• Docker. (z.d.). Swarm mode key concepts. Docker Documentation. Geraadpleegd op 7 oktober 2021 van https://docs.docker.com/engine/swarm/key-concepts
• Drewel, K. (2021, 26 februari). Kubernetes vs. Docker (Swarm): wat zijn de verschillen? True. Geraadpleegd op 7 oktober 2021 van https://www.true.nl/blog/kubernetes-vs-docker-swarm-verschillen
• Poulton, N. (2018, 4 januari). Docker Deep Dive [Video]. Pluralsight. Geraadpleegd op 6 oktober 2021 van https://www.pluralsight.com/courses/docker-deep-dive-update
• Sengupta, S. (2020, 24 november). Kubernetes vs Docker Swarm: Comparing Container Orchestration Tools. BMC Blogs. Geraadpleegd op 7 oktober 2021 van https://www.bmc.com/blogs/kubernetes-vs-docker-swarm
• Rosen, C. (2021, 3 april). Docker Swarm vs. Kubernetes: A Comparison. IBM. Geraadpleegd op 7 oktober 2021 van https://www.ibm.com/cloud/blog/docker-swarm-vs-kubernetes-a-comparison
• Sumo Logic, Inc. (2021, 1 juni). What is Docker Swarm? Sumo Logic. Geraadpleegd op 6 oktober 2021 van https://www.sumologic.com/glossary/docker-swarm

K3s… Weer een buzzword of best in class Kubernetes distributie voor lokale development?

Luuk ten Haaf, oktober 2021.

Deze blog bevat daarom configuratie en code en zorgt ervoor dat medestudenten hiermee aan de slag kunnen. Op basis van de AIM-methodekaarten beantwoord ik een hoofdvraag uit. Voor het beantwoorden van de deelvragen maak ik gebruik van drie onderzoeksgebieden: bibliotheek, veld en werkplaats.

De hoofdvraag van mijn onderzoek is:

Hoe kunnen de Ingress en LoadBalancer resources in K3s effectief worden ingezet binnen een tweeweeks DevOps project op een lokaal development cluster?

Per deelvraag geef ik aan welke onderzoeksmethode ik ga gebruiken. Ook motiveer ik waarom ik voor die onderzoeksmethode heb gekozen.

• Deelvraag 1: Wat is K3s, en waarin verschilt dit met de standaard Kubernetes distributie? Voor het beantwoorden van deze vraag voor ik een Literature Study (HBO-i, 2021) uit. Op internet is veel informatie over K3s te vinden in de vorm van blogs en documentatie. Deze informatie kan ik goed gebruiken om een antwoord te geven op deze deelvraag.

• Deelvraag 2: Welk besturingssysteem gebruikt mijn samenwerkingsgroep en hoe installeer je daar K3s op? Om deze vraag te beantwoorden voer ik eerst een kleine Survey (HBO-i, 2021) uit. Ik wil namelijk dat deze vraag zo beantwoord wordt dat hij relevant is voor mijn samenwerkingsgroep. Praktische voorbeelden voor Linux terwijl de samenwerkingsgroep Windows gebruikt is onwenselijk.

• Deelvraag 3: Op welke wijze kan een applicatie, draaiend in een K3s cluster, opengesteld worden zodat verbinding van buitenaf mogelijk is? Voor deze deelvraag voer ik een werkplaats onderzoek uit. Ik heb gekozen voor de Prototyping methode (HBO-i, 2021). Dit zal een zeer praktisch hoofdstuk worden waarin ik aan de hand van een prototype aantoon hoe verbinding van buitenaf mogelijk is. Op dit prototype kan verder gebouwd worden in het twee weken durend DevOps project.

Ik heb voor K3s gekozen omdat deze technologie in het verlengde ligt van Kubernetes gebruikt in lesweek 4 – Orchestration. Ik merkte van studenten om mij heen dat ze het gebruiken van een LoadBalancer en Ingress lastig vonden. Uit vorige ervaring wist ik dat K3s het gebruik van een LoadBalancer en Ingress makkelijk maakt. Door het schrijven van deze blog hoop ik mijn medestudenten te overtuigen K3s toe te passen als lokaal development cluster binnen een klein DevOps project.

Ik heb variëteit in de onderzoeksmethodes gezocht om zo de kwaliteit van het onderzoek te verhogen. Door eerst online materiaal te bestuderen, daarna een enquête af te nemen en dan pas een prototype te bouwen kan ik het onderzoek zo relevant mogelijk opstellen. Mijn mix van onderzoeksmethodes past het meest bij het “Choose fitting technology” pattern (HBO-i, 2021).

Aan het eind van deze blog weet je wat K3s is en heb je een K3s cluster draaiend op Windows of MacOs. Binnen dit cluster maak je gebruik van een LoadBalancer en Ingress om naar containers te verbinden.

Relatie tussen K3s en Kubernetes

K3s is een lichtgewicht en door de CNCF gecertificeerde Kubernetes distributie. Deze is productieklaar, gemakkelijk om te installeren en komt in een binary van minder dan 100 MB. De ontwikkelaars van K3S geven aan dat het geweldig werkt voor Internet of Things, Continuous Integration, Development en op ARM gebaseerde devices (k3s-io, 2021). Om dit te bereiken hebben de ontwikkelaars een aantal wijzingen aangebracht, hieronder een opsomming van de belangrijkste.

• Het is verpakt in één binary.
• Het voegt ondersteuning toe voor sqlite3, MySQL en Postgres als default storage backend.
• Het heeft minimale tot geen OS-afhankelijkheden.
• Storage drivers zijn verwijderd.
• Cloud provider drivers zijn verwijderd.

Doordat het een lichtgewichte Kubernetes distributie is kun je deze gebruiken op minder krachtige hardware zoals een Raspberry Pi (Roy, 2021). Met de standaard Kubernetes zou dit niet mogelijk zijn vanwege zijn grote voetafdruk voor zowel geheugen als CPU (Boyd, 2021). Om het geheugengebruik in K3s te verminderen worden alle componenten, voor een Kubernetes cluster, in één proces uitgevoerd. K3s is daarom ook geschikt als development cluster omdat het snel en eenvoudig op te zetten is en weinig resources op je laptop gebruikt. K3s levert daarbij add-ons met standaardinstellingen die ervoor zorgen dat het cluster “out of the box” gebruikt kan worden (Boyd, 2021). Als je dit vergelijkt met Kubernetes ben je zelf verantwoordelijk om dependencies te installeren. Om gebruik te maken van een LoadBalancer ben je met de standaard Kubernetes afhankelijk van een Cloud Provider. K3s bundelt Klipper-lb als ingebouwde LoadBalancer provider. Ook wordt Traefik meegeleverd als Ingress provider. Iets wat in de standaard Kubernetes niet aanwezig is (k3s-io, 2021).

Installeren van K3s en het opzetten van een cluster

Ik heb eerst onderzocht welke besturingssystemen de studenten in mijn samenwerkingsgroep gebruiken. Ik heb de opties Windows, MacOs en Linux in een enquête verstuurd. De enquête heb ik zelf ook ingevuld zodat er compleet beeld ontstaat. In de tabel onder deze tekst staan de resultaten. Drie studenten gebruiken Windows en één student MacOs. Aan de hand van deze resultaten heb ik besloten om te zoeken naar een manier om K3s te installeren voor zowel Windows als MacOs gebruikers.

De installatiestappen op de officiële K3s website geven aan dat K3s op elke moderne Linux distributie geïnstalleerd kan worden (Rancher, 2021). Echter is Windows geen Linux distributie dus heb ik gezocht naar een vervangende oplossing. Via de blogpost van Jason Yee (Yee, 2020) en de officiële K3s documentatie ben ik bij k3d uitgekomen (Rancher, 2021). K3d is een wrapper om K3s heen zodat het in Docker containers gedraaid kan worden. De enige requirements zijn Docker en kubectl (“K3d”, 2021). Deze dependencies kunnen op zowel Windows als MacOs geïnstalleerd worden. Om k3d op MacOs te installeren moet je het commando brew install k3d uitvoeren. Op Windows maak je gebruik van chocolatey. Door het commando choco install k3d uit te voeren wordt k3d op Windows geïnstalleerd. Alle commando’s die volgen in deze blog kunnen op zowel Windows als MacOs uitgevoerd worden in de terminal.

Je eerste K3s cluster

Nu we K3d geïnstalleerd hebben kunnen we ons eerste cluster aanmaken. Dit doen we door gebruik te maken van het commando k3d cluster create <clusternaam>. Ik kies ervoor om “mijncluster” als naam te gebruiken. Door het volgende commando uit te voeren wordt een K3s cluster met één node aangemaakt: k3d cluster create mijncluster.

Als we daarna kubectl get nodes uitvoeren krijgen we te zien dat ons cluster uit één node bestaat.

Om te demonstreren dat K3s ook met meerdere nodes werkt gaan we een cluster aanmaken met drie nodes. We gebruiken hetzelfde create commando als eerst maar geven nu één extra optie mee. Verwijder eerst de zojuist aangemaakt cluster door het volgende commando uit te voeren: k3d cluster delete mijncluster. Om een cluster aan te maken met 1 server node en 2 agent nodes voer je het volgende commando uit: k3d cluster create mijncluster --agents 2. Als we nu kubectl get nodes uitvoeren zien we 2 extra nodes.

Nu we op hoofdlijnen weten wat K3s is en hoe we een cluster aan kunnen maken is het tijd om het cluster daadwerkelijk te gaan gebruiken.

Verbinding maken met een applicatie in K3s.

Om aan te tonen hoe we verbinding kunnen maken met een applicatie draaiend in K3s ga ik een klein prototype bouwen. Stap voor stap beschrijf ik mijn handelingen zodat je zelf ook mee kunt doen. Aan het einde van deze sectie heb je een whoami (https://hub.docker.com/r/containous/whoami) applicatie geïnstalleerd op je K3s cluster. Deze applicatie kun je bereiken door te navigeren naar whoami.localhost. Hiermee demonstreren we dat de LoadBalancer en Ingress naar behoren werkt. In de afbeeldingen hieronder is de eindsituatie te zien waar we naartoe gaan werken.

We beginnen met het aanmaken van een nieuw cluster. Omdat we nu applicaties in het cluster willen benaderen moeten we het create commando iets aanpassen. Voer het volgende commando uit: k3d cluster create -p "80:80@loadbalancer" mijncluster. Met de p optie geven we aan dat poort 80 lokaal doorverwijst naar poort 80 op de ingebouwde Klipper-lb (LoadBalancer) van K3s.

Als eerste maken we een nieuwe deployment voor de whoami applicatie. Laten we het aantal replicas op 3 zetten zodat we kunnen verifiëren of de Ingress wisselt tussen de verschillende pods die aangemaakt worden met deze deployment. De deployment krijgt een label whomai zodat we ernaar kunnen verwijzen in de service die we zo dadelijk aanmaken.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
spec:
  replicas: 3
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
      - name: whoami-container
        image: containous/whoami

De volgende stap is het aanmaken van een service. We specifiëren hier dat we een service van het type ClusterIP willen. De pods die we targeten hebben het label app: whoami. Dat hebben we zojuist in de deployment ook gespecificeerd. Als laatst geven aan dat poort 80 doorverwijst naar poort 80 in de pod.

apiVersion: v1
kind: Service
metadata:
  name: whoami
spec:
  type: ClusterIP
  ports:
  - targetPort: 80
    port: 80
  selector:
    app: whoami

De laatste stap is het configureren van de Ingress. In de spec geven we aan dat we als host whoami.localhost willen gebruiken. Aan het einde van de spec specificeren we op welke service en poort we aan willen sluiten.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami
  annotations:
    kubernetes.io/ingress.class: traefik
spec:
  rules:
  - host: whoami.localhost
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: whoami
            port:
              number: 80

Door al deze yaml bestanden uit te voeren zou in theorie de whoami applicatie op whoami.localhost benaderbaar moeten zijn. Laten we dat testen. Als ik in mijn browser navigeer naar whoami.localhost krijg ik een pagina te zien met daarop de hostname van de pod. Wanneer ik de pagina ververs krijg ik een andere hostname te zien. We kunnen dus concluderen dat het prototype werkt en we nu gebruik maken van een LoadBalancer en Ingress om onze whoami applicatie te benaderen.

Hostname bij eerste bezoek.	Hostname na het verversen van de pagina.

Afsluiting

In deze blog heb ik geschreven dat K3s een lichtgewicht Kubernetes distributie is die “out of the box” direct gebruikt kan worden. Om dit te bewijzen heb ik laten zien hoe je K3s gemakkelijk op MacOs en Windows kan installeren en hoe je effectief gebruik kunt maken van de meegeleverde LoadBalancer en Ingress. Ik ben ervan overtuigd dat we deze technologie in kunnen zetten tijdens het beroepsproduct als lokaal development cluster.

Bronnen

• Yee, J. (2020, 6 december). Kubernetes & Rancher 2.5 on a Win 10 laptop with k3d & k3s to deploy nginx locally. Geraadpleegd op 6 oktober 2021 van https://itnext.io/kubernetes-rancher-2-5-on-your-windows-10-laptop-with-k3d-and-k3s-7404f288342f
• k3s-io. (2021, 12 juli). GitHub - k3s-io/k3s: Lightweight Kubernetes. Geraadpleegd op 6 oktober 2021 van https://github.com/k3s-io/k3s
• HBO-i. (2021, 2 juli). ICT research methods. Geraadpleegd op 6 oktober 2021 van https://ictresearchmethods.nl
• Roy, H. (2021, 23 september). K8s vs k3s: The Comprehensive Difference. Geraadpleegd op 6 oktober 2021 van https://www.p3r.one/k8s-vs-k3s
• Boyd, W. (2021, 17 juni). 5 Reasons to Use K3s. Geraadpleegd op 6 oktober 2021 van https://acloudguru.com/blog/engineering/5-reasons-to-use-k3s
• Rancher. (2021, 9 augustus). K3s - Lightweight Kubernetes. Geraadpleegd op 6 oktober 2021 van https://rancher.com/docs/k3s/latest/en/
• K3d. (2021, 17 september). Geraadpleegd op 6 oktober 2021 van https://k3d.io/v5.0.0

Nanoservices: microservices, maar dan kleiner

Abdel Hajou, oktober 2021.

In het kader van de minor DevOps heb ik het in dit blog over hoe je met nanoservices een systeem opdeelt in hele kleine services met elk één taak. Ik leg uit wat precies het verschil is tussen microservices en nanoservices en waarom je voor nanoservices moet kiezen (of juist niet). Met behulp van het Serverless framework schrijf ik zelf een nanoservice, natuurlijk op een DevOps manier.

There's always a smaller fish

We kennen microservices als modulaire, onafhankelijke applicaties die op zichzelf deploybaar en schaalbaar zijn. Microservices kunnen een oplossing zijn voor bedrijven die tegen problemen aan lopen zodra hun applicatie begint te schalen. Nieuwe features ontwikkelen blijkt een stuk complexer te zijn zodra je met 1000 developers aan dezelfde codebase moet werken (Kim et al., 2016, pp. 182–183).

Een nanoservice is een stuk code met één publieke methode die net zoals een microservice autonoom is. Microservices hebben één verantwoordelijkheid, en nanoservices hebben één taak. Een microservice zou dus verantwoordelijk kunnen zijn voor het afrekenen van een bestelling, maar een nanoservice kan zo klein zijn dat het alleen de taak heeft om een bevestigingsmail naar de klant te sturen (Ebi, 2020).

Serverless

Een belangrijke eigenschap van nanoservices is dat ze vaak serverless zijn. Dit betekent niet dat het niet op een server draait, maar dat een cloud provider verantwoordelijk is voor het beheren en bereikbaar houden van de infrastructuur. Als developer hoef je je dan alleen nog zorgen te maken over in welke runtime je nanoservice draait (RedHat, 2017). Dit gaat dus nog een stapje verder dan microservices. Microservices deploy je meestal in een container met een besturingssysteem. Bij nanoservices is zelfs het besturingssysteem niet meer relevant.

Replicas: ∞

Bij een serverless architectuur draait je applicatie on-demand. Zodra je een request stuurt naar de nanoservice (of er treedt een event op), zorgt de cloud provider (bijvoorbeeld AWS) dat er een nieuwe instantie van je nanoservice opgestart wordt. Zodra de request of event afgehandeld is, wordt de nanoservice weer uitgezet (RedHat, 2017).

Pitstop uitbreiden met een nanoservice

Nu we weten wat het verschil is tussen een microservice en een nanoservice, gaan we een nanoservice schrijven. Ik gebruik voor dit voorbeeld de Pitstop applicatie van Edwin van Wijk (2017). Dit is een werkplaats management systeem voor een fictieve auto-garage. Deze applicatie wordt als voorbeed gebruikt voor verschillende software-architectuur concepten zoals microservices, Domain Driven Design en CQRS.

Wat je nodig hebt

• NodeJS
• Optioneel: een AWS account (Free Tier)

Wat we gaan maken

Om in Pitstop een reparatie te plannen moet je eerst je voertuig registeren. Hiervoor vul je het kentekennummer, merk en type van je auto in. Het merk en type van een auto kun je in Nederland eigenlijk afleiden uit het kentekennummer. Hiervoor kunnen we een API van de RDW gebruiken, maar in het kader van Ubiquitous Language willen we onze Engelse codebase niet mengen met Nederlandse termen. Ook heb je voor deze API een secret key nodig, en deze willen we natuurlijk niet openbaar maken in onze front-end. Laten we hier een nanoservice voor gaan schrijven met behulp van de Serverless documentatie.

Yet Another YAML file

Om te voorkomen dat je voor elke wijziging in je serverless function door 100 AWS menu's moet klikken, maken we gebruik van een serverless application framework. Dit maakt het mogelijk om je nanoservice ook lokaal te testen en voorkomt dat je vast komt te zitten aan één cloud provider. Er zijn meerdere serverless application frameworks, maar hier gebruiken we Serverless Framework omdat deze open-source is en het makkelijker maakt om voor meerdere cloudplatformen te ontwikkelen (Microsoft, z.d.).

Serverless project opzetten

# Serverless draait zelf op NodeJS, maar je kunt je nanoservices in andere talen programmeren
$ npm install -g serverless
# Serverless heeft standaard templates voor veelgebruikte talen, zoals NodeJS op AWS
$ sls create --template aws-nodejs --path get-car-brand

De aws-nodejs template maakt twee bestanden aan. In serverless.yml staat de configuratie van je nanoservice, zoals de runtime, hoeveelheid geheugen en het platform waarop je wil deployen. In handler.js staat de entrypoint van je nanoservice. Deze methode wordt uitgevoerd zodra je de nanoservice aanroept. Deze heeft een event parameter. In het geval van een REST API zou dit dus de request kunnen zijn.

Serverless functie schrijven

Onze nanoservice zal niet veel meer doen dan een request sturen naar de RDW API en het resultaat vertalen naar het Engels.

# Om HTTP requests te sturen kunnen we in NodeJS de axios library gebruiken
$ npm i axios

'use strict';
const axios = require('axios');

const SECRET_KEY = process.env.RDW_API_KEY;

module.exports.getCarBrandAndType = async (event) => {

  const voertuigGegevens = await axios
    .get(`https://opendata.rdw.nl/resource/m9d7-ebf2.json?kenteken=${event.licensePlate}`, 
        { headers: { 'X-App-Token': SECRET_KEY }});
  
  // Onze nanoservice werkt als een HTTP API en geeft dus een response terug.
  // Je zou hier eventueel ook een event kunnen publishen naar een event queue.
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        brand: voertuigGegevens.data[0].merk,
        type: voertuigGegevens.data[0].handelsbenaming
      }
    ),
  };
};

Omdat we de nanoservice niet lokaal aanroepen, maar via HTTP, moeten we een event definïeren. Ook heb ik de handler methode een andere naam gegeven, dus pas ik dit aan in de serverless.yml.

functions:
  getCarBrandAndType:
    handler: handler.getCarBrandAndType
    events:
      - http: GET getCarBrandAndType

We kunnen onze nanoservice nu met één command deployen naar onze gewenste cloud provider. Ook dit definieer je in je serverless.yml.