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:

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)
Product increment, Bron: <https://www.flickr.com/photos/otacke/13217723304>

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.

Pitstop

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.

Pitstop

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

Last change: 2025-01-13