De liefhebbers van Seinfeld weten dan direct waar dit over gaat. De postbode Newman en aartsrivaal van Jerry Seinfeld. In dit geval hebben wij het over Newman de Postman add-on.  Deze add-on is een CLI om Postman collecties te runnen.  Postman is na de opkomst van REST de de-facto standaard voor het testen van je API’s en is in de loop der jaren flink uitgebreid. Newman geeft je dus de mogelijkheid om een collectie aan API’s op de commandline uit te voeren, hiermee kunnen we dan geautomatiseerd Postman script runnen in de CI/CD pipeline. Dit werkt als volgt.

Installeren Newman

Newman is te installeren van uit een npm package:

De interface is eenvoudig en doeltreffend. Het is mogelijk om naast een collectie ook een specifieke Postman environment mee te geven:

Deze tool geeft je nu de mogelijkheid om dus ook Postman collections geautomatiseerd in een pipeline te kunnen starten door de integratie met Azure DevOps.

Integratie met Azure DevOps

Er is een specifieke task beschikbaar in Azure DevOps om Newman scripts te kunnen starten. Deze is te vinden op de Visual Studio Marketplace.

Voor men in de release pipeline gebruik kan maken van deze task dient wel eerst Newman op de build agent geïnstalleerd te worden. Dit kan gewoon op dezelfde manier als een lokale install met een custom npm command.

Vervolgens kan men aan deze nieuwe taak de Postman collection en environment meegeven. Let wel dat jUnit als reporter wordt geselecteerd mocht men de resultaten van een Postman test terug willen zien. Geef ook een directory op waar de resultaten van de rest naar toe moeten.

De test resultaten van de Postman test kan men dan in Azure DevOps inzien.

Het gebruik van Newman CLI in combinatie met Postman is een vrij simpele, lichtgewicht  en doeltreffende oplossing voor het testen van API’s.  Deze zijn ook goed lokaal te bouwen en testen. Daarnaast sluit het ook nog eens goed aan huidige marktstandaard. Al met al een prima oplossing voor het ontwikkelen van een integratietest.

Auteur: Patrick Bes, Bergler Competence Center © 2019

Het laatste jaar is het gebruik van Microsoft Teams enorm gestegen. Dit is Microsofts derde poging om voet aan de grond te krijgen op de markt van collaboratie en communicatie tools. Een recent onderzoek van Spiceworks toont aan dat Teams concurrent en marktleider Slack voorbij is. Dit is een hele prestatie in een korte tijd.

Yammer vs Skype vs Teams

Terugkijkend op de soort initiatieven die Microsoft op dit gebied heeft gehad blijkt dat er meerdere afkomstig zijn uit externe aankopen. Zo is in 2012 $1.2 miljard betaald voor het platform van Yammer.  Dit heeft op een klein gebied wel wat tractie gehad, maar is nooit uitgegroeid tot wereldwijde standaard.

Daarvoor heeft Microsoft in 2011 nog eens $8,5 miljard neergelegd voor Skype. Skype wordt voornamelijk als (Audio en Video) Chat applicatie in de markt gepositioneerd. En uiteindelijk komt men in 2016 met een eerste versie van Microsoft Teams op de Markt. Volgens de verhalen, nadat Satya Nadella & Bill Gates hebben besloten dat het kopen van Slack voor $8 miljard geen goed idee is. Ze kunnen tenslotte ook zelf iets ontwikkelen.

Uiteindelijk heeft Microsoft dus bijna $10 miljard uitgegeven, hebben ze drie verschillende producten, en is de propositie wanneer men welk product moet gebruiken op zijn best vaag. Als we een aantal features naast elkaar zetten zien we het volgende:

Deze 3 applicaties zitten toch sterk in elkaars vaarwater. We weten dat  Yammer meer in de Messaging hoek zit en Skype meer in de Audio/Video hoek. Teams daarentegen kan eigenlijk beide. Skype biedt wel een aantal functies voor instant messaging, maar het is duidelijk dat het geen applicatie is waar het hebben van tekst conversaties met meerdere personen de belangrijkste feature is. De feature “call-in functions” gaat over het bieden van de mogelijkheid om deel te nemen aan een meeting met een extern telefoonnummer. Zowel Skype als Teams biedt deze optie maar het is vanuit Teams wel eenvoudiger om connectie te maken naar je bestaande telefonie infrastructuur.

Teams heeft hiernaast nog een aantal andere leuke nuttige features, denk bijvoorbeeld aan het wisselen van device (laptop naar mobiel) tijdens een meeting of een blur van je video achtergrond, als je niet wilt dat tekeningen van de kinderen aan de muur of erger nog de gestolen van Gogh zichtbaar is.

Microsoft positioneert Teams duidelijk als de opvolger van Skype for Business maar er is nog geen end-of-life datum voor Skype for Business aangekondigd. Meer informatie over een upgrade naar Teams is hier te vinden. Het is duidelijk dat als je nu gebruik maakt van Yammer of Skype for Business dat Teams de way forward is.

Teams vs Slack

Uiteindelijk is Teams begonnen als directe concurrent van Slack en niet de reeds beschikbare Microsoft tools. Dus wat een interessante vraag is: wat is het verschil tussen Slack en Teams?

Microsoft heeft goed gekeken naar Slack en ze hebben strategische keuzes gemaakt om op een aantal punten een beter product te bieden. Beide hebben 3 verschillende betaal modellen waarbij de kosten elkaar op het eerste gezicht niet veel ontlopen, maar Teams is onderdeel van het Office 365 plan waarbij men Teams er dus “gratis” bij krijgt. Qua features biedt Teams ook meer dan de set van Slack.

Maar ondanks dat het heel veel features biedt zijn er zeker nog dingen die missen of nog niet helemaal af voelen. Een voorbeeld hiervan is de mobiele app. Deze heeft zo nu en dan aanmeldissues waarbij de app aangeeft dat je geen onderdeel uit maakt van een organisatie terwijl dit wel het geval is. De Windows 10 app werkt beduidend beter, maar claimt wel aanzienlijk resources. Dus er zijn nog zeker zaken te verbeteren. Ondanks deze tekortkomingen is Teams inmiddels een behoorlijk volwassen product, en zeker de overweging waard indien men de keuze moet maken.

Slack is een tool die een grote userbase heeft en ook zeer veel integratiemogelijkheden biedt met andere tools. Op dit gebied heeft Teams nog wel wat in te halen, maar worden er ook grote stappen gemaakt.

Conclusie

Goed, we hebben een aantal zaken op een rijtje gezet maar wanneer kiezen we nu welke tool? Ik gebruik zelf het onderstaande flow diagram om de keuze te beargumenteren.

Deze keuze blijft vaak toch enigszins arbitrair en een gevoelskwestie, omdat het tools zijn waar men dagelijks mee werkt en verknocht aan is geraakt. Het überhaupt hebben van een collaboratie en communicatie tool in zijn algemeenheid is wellicht de allerbelangrijkste keuze.

Auteur: Patrick Bes, Bergler Competence Center © 2019

Kubernetes is natuurlijk een super krachtig en mooi container orchestration platform. Ondanks dat de meeste zichzelf respecterende ontwikkelaars zullen claimen alleen nog gebruik te willen maken van de CLI tool kubectl, is voor sommige beginnende- of wat minder keyboard georiënteerde senior kubernetes adepts, het dashboard een mooie tool om snel en goed inzicht te krijgen in de status van het platform. In dat geval is kubectl proxy al snel het eerste commando wat men zal gebruiken.

De visuele indicatoren over de status van de deployments, pods, replica’s en de hoeveelheid CPU of memory gebruik zijn vaak een heel handig hulpmiddel in het geval men moet troubleshooten.

Maar zoals de oom al aan Spider-Man vertelde “With great power, comes great responsibility”. Het kubernetes dashboard heeft standaard veel mogelijkheden die men wellicht niet aan iedereen beschikbaar wil stellen, zoals het inzien van de secrets het verwijderen van deployment of het aanpassen van yaml bestanden. Hoe geeft men nu gebruikers nu wel toegang tot het kubernetes dashboard maar geen toegang tot alle overige beschikbare functionaliteiten?

Dit is mogelijk door gebruikers b.v. lees rechten te geven op kubernetes en deze uit te breiden met een minimale set aan rules welke benodigd zijn om het dashboard te starten. Dan kan men als gebruiker het dashboard openen met alleen lees rechten. De gebruikers van kubernetes moeten hiervoor natuurlijk wel inloggen met een een persoonlijke account, dit kan men bewerkstelligen door kubernetes te koppelen met een RBAC (role based access control) uit b.v. AzureAD. Meer informatie hierover kan men hier vinden.

Inrichting “alleen lees” rechten role

Kubernetes heeft een aantal standaard cluster rollen beschikbaar. De “view” role is er hier één van. Deze role geeft gebruikers rechten om alles (behalve de secrets) in te zien, maar ze kunnen niets aan passen.

Deze rol is een ideaal startpunt om de rechten voor het kubernetes dashboard aan toe te voegen. Men kan de configuratie yaml van deze bestaande rol uitvragen met het volgende commando: kubectl get clusterrole view –o yaml

Vervolgens kan men hier een nieuwe clusterrole van maken door de naam aan te passen (in dit geval ‘rbacview’), en de volgende minimale set van rechten voor het dashboard eraan toe te voegen:

Vervolgens kan men dan een ClusterRoleBinding aanmaken voor een specifieke group uit AzureAD:

De clusterrolebinding heeft een referentie naar de clusterrole (in dit geval ‘rbacview’). Met deze wijziging heeft de gespecificeerde groep nu de mogelijkheid om het kubernetes dashboard te open met alleen lees rechten.

Auteur: Patrick Bes, Bergler Competence Center © 2019

Een product backlog kan al snel onoverzichtelijk worden en is meestal te gedetailleerd om met stakeholders (binnen hoger management) de prognose te bespreken van toekomstige ontwikkeling. Binnen Azure DevOps kun je al een hoop structuur aanbrengen door gebruik te maken van epics en features.

Het voordeel van de epics en de features is dat je stories mooi kunt groeperen, het nadeel is dat de lijst niet langer noodzakelijk op volgorde van prioriteit staat omdat je in veel gevallen aan meerdere features parallel werkt. Ikzelf vind het belangrijk om een effectief praatplaatje te hebben om met stakeholders over de roadmap te kunnen praten. De laatste tijd heb ik hiervoor de feature timeline plugin gebruikt en ik ben hier erg over te spreken:

De plugin geeft een overzichtelijk scherm waarin de epics en de features uitgezet zijn in de tijd. In het verleden kwamen features alleen op de tijdlijn terecht door de onderliggende story planning. Inmiddels hebben ze dit gelukkig los gelaten waardoor je onafhankelijk van de stories de features op de tijdlijn kunt slepen en eventueel vergroten of verkleinen. Daarnaast geeft de plugin ook de voortgang van de onderliggende stories aan zodat ook tijdens de ontwikkeling het scherm een mooi overzicht van de voortgang blijft geven.

Hoe in te richten

De feature en epic timelines zijn niet standaard actief in Azure DevOps. Deze zul je via de marketplace moeten installeren.

Bij een standaard configuratie van Azure DevOps staan de epic navigation levels uit. In dat geval zul je deze eerst moeten inschakelen. Als epic niveau gebruik ik meestal de hoog-over doelstellingen van een kwartaal.

Auteur: Menno Jongerius, Bergler Competence Center © 2018

Voor degene onder ons die wel eens te maken hebben met het verwerken van tekst- of csv-bestanden zal het bekend voorkomen: welke encoding moet ik gebruiken om de bestanden juist in te lezen? Als je dan de lijst met encoding standaarden doorneemt zou je misschien geneigd zijn om de default encoding te gebruiken. Toch is het een slecht idee om gebruik te maken van de default encoding om de volgende redenen:

• De default encoding slaat geen informatie op over welke encoding gebruikt wordt waardoor het voor de ontvanger van de encoded informatie niet mogelijk is om te achterhalen met welke encoding de informatie opgesteld is. Wanneer je UTF-8 of UTF-16 encoding gebruikt, is het wel mogelijk om een handtekening aan de encoded informatie te geven waardoor de ontvanger weet welke encoding gebruikt wordt.
• Encoding default gebruik de encoding die ingesteld is op de computer, deze encoding kan echter eenvoudig gewijzigd worden en zal bovendien mogelijk niet hetzelfde zijn wanneer informatie tussen verschillende computers gedeeld wordt. Het gevolg kan zijn dat encoded informatie niet juist gedecoded kan worden.
• Encoding default gebruikt een ANSI-codering als basis waardoor maar een klein gedeelte van de karakters in de unicode standaard gebruikt kan worden.

Als je de default encoding niet kunt gebruiken, welke codering gebruikt je dan wel? Ik heb goede ervaringen met het gebruik van UTF-8 of UTF-16, deze ondersteunen alle tekens die ik in de praktijk tegenkom. Voor latin based talen is UTF-8 prima, wanneer je ook niet latin talen wilt ondersteunen is UTF-16 de beste keuze. Een encoding met een van deze standaarden zal in de praktijk wat meer ruimte vergen dan de meer beperkte default / ANSI-coderingen, maar scheelt je een hoop kopzorgen wanneer je diakritische tekens gebruikt in tekst.

We zien steeds meer organisaties van monolithische applicaties naar modulaire systemen bewegen. Een uitdaging die binnen dergelijke distributed systemen komt kijken is de manier waarop de modules onderling communiceren. Een veelgebruikte oplossing voor asynchrone communicatie, is om een messaging service zoals RabbitMQ te gebruiken. Wat je dan in de praktijk bij veel teams ziet is een oplossing zoals in het onderstaande diagram vereenvoudigd weergegeven:

Een actie op service 1 waarop een andere service moet reageren wordt als event op de queue gezet. Service 2 implementeert een listener die het event van de queue haalt en vervolgens verwerkt. Zolang de applicatie relatief klein is, functioneert deze manier van werken prima. Het wordt echter een stuk lastiger naarmate de applicatie groeit en de services door verschillende teams beheerd worden:

• Om de beschreven action te implementeren wordt het team dat service 1 beheert afhankelijk van een listener die door een ander team gebouwd moet worden.
• Er ontstaat een wederzijdse afhankelijkheid van de beide services van 1 message queue, welk team is nu verantwoordelijk voor events die niet opgepakt kunnen worden?
• Events afkomstig van service 1 komen niet via het publieke endpoint van service 2 binnen, maar via een achterdeur. Dit is een aanzienlijke verhoging van de complexiteit en kan grote problemen geven bij versie updates.
• Het documenteren van publieke REST api’s is veel eenvoudiger dan queue berichten.

Al met al de nodige redenen om af te stappen van de bovenstaande implementatie van een message broker laag.

Een alternatieve implementatie
Met een aantal relatief eenvoudige aanpassingen is het mogelijk om de services beter te isoleren en teams onafhankelijk van elkaar te laten werken:

• Services communiceren alleen met elkaar via de publieke endpoints, wat de complexiteit van de communicatie drastisch verlaagd.
• Waar asynchrone communicatie nodig is wordt een message broker gebruikt, echter de service zelf pakt deze asynchrone events op en pushed het bericht door naar andere service endpoints.
• De enige afspraak voor samenwerking tussen services is via hun REST contract. Teams hebben meer vrijheid om eigen tools en technologie te kiezen waardoor meer maatwerk ontstaat.

Welke winst hebben we nu geboekt:

• Teams zijn niet afhankelijk van andere teams voor het opleveren van features (mits er geen volledig nieuwe endpoints nodig zijn, maar dat is meestal niet het geval).
• Een team is volledig verantwoordelijk voor het afhandelen van een action inclusief het aftrappen van vervolgstappen.
• Het is volstrekt helder welk team verantwoordelijk is voor de queue van service 1.
• Het is relatief eenvoudig om service 1 inclusief de propagatie geïsoleerd automatisch te testen inclusief het afhandelen van foutmeldingen die van service 2 terugkomen.

Auteur: Menno Jongerius, Bergler Competence Center © 2018

Dit is het derde artikel in de serie over Domain Driven Design.

• Artikel 1 : Introductie
• Artikel 2: Het model

Om het begrip rond aggregates, entiteiten en value objecten goed te begrijpen is begrip nodig van de zogenaamde “life cycle” van objecten in het algemeen. De DDD manier beschrijft de status van een object zijnde: “actief”, “verwijderd” of “gearchiveerd”.

Een “actief” object is in het geheugen geladen (bijvoorbeeld uit een database) en wordt actief mee gewerkt of gebruikt om entiteiten binnen een bounded context te benaderen.

Een “verwijderd” object krijgt deze status eigenlijk middels een “onzichtbaar” vlag omdat entiteiten eigenlijk nooit verwijderd worden (is overigens een uitdaging in het perspectief van GDPR en “mij vergeten”).

Een “gearchiveerd” object is opgeslagen en niet geladen in het geheugen van de applicatie.

Bovenstaande is door Eric Evans grafisch weergegeven in zijn boek “Domain Driven Design, tackling the complexity in the heart of software”.

Moderne software oplossingen bevatten snel diepgaande structuur van objecten middels verschillende lagen. In aanvulling hierop worden software oplossingen steeds meer gebruikt via verschillende apparaten en kunnen deze draaien op verschillende besturingssystemen. Veel gebruikers muteren gegevens tegelijkertijd hierdoor. De uitdaging is daarom om de waarheid van de objecten te garanderen. Deze consistentie van veranderingen “eventual consistency” is DE uitdaging van DDD gedreven oplossingen.

Consistentie wordt bepaald via een verzameling van regels, in DDD termen “invariants” genoemd. Deze “invariants” moeten op 1 plek worden vastgelegd. Zij bepalen de samenhang van de objecten in de bounded context en zorgen ervoor dat 1 waarheid blijft bestaan. Die ene plek is het hoofd object in de bounded context. Dit hoofd object wordt de aggregate root genoemd. Doordat dit type object verantwoordelijk is om de “invariants” te bewaken, moet het de rol spelen van de “poortwachter” voor de bounded context.

In andere woorden, alleen via de aggregate root kan de bounded context en haar inhoud worden aangesproken en worden gewijzigd.

De volgende regels worden in acht genomen voor aggregates en hun bounded contexts:

• De aggregate zorgt voor consistentie binnen de bounded context. Dit betekent dat het verwerken van gerelateerde objecten binnen 1 transactie moet plaatsvinden
• De aggregate objecten hebben een identiteit die over alle bounded contexten geldt. Op deze manier zijn uitwisselingen mogelijk van gegevens tussen de bounded contexten. Overige entiteiten binnen een bounded context, hebben een lokale identiteit. Er bestaat geen garantie dat voor entiteiten met dezelfde naam en identiteit maar in verschillende bounded contexten, zij ook identiek zijn. Immers, bijvoorbeeld de entiteit “Person” kan in de bounded context van Employee totaal iets anders voorstellen als in de bounded context Sales
• De opbouw van de structuur van objecten uit een opslag, gebeurt altijd via de aggregate. De aggregate heeft kennis van de interne structuur in de bounded context
• Een aggregate kan referenties hebben naar andere aggregates in andere bounded contexten
• Zodra er wijzigingen worden aangebracht via de aggregate, moeten deze onmiddelijk worden verwerkt in de opslag en moeten alle regels voor consistentie zijn nageleefd

Aggregates is dus een speciaal object in DDD. Conform de “ubiquitous language” is de aggregate dus een entiteit met speciale eigenschappen en gedrag. Andere objecten binnen de bounded context zijn dus of reguliere entieiten of value objects.

Value objects, weer een abstracte term die toelichting vereist. Het verschil tussen een entiteit en een value object is dat de laatste geen unieke identiteit heeft. Ook is een value object onwijzigbaar. Waarom zou je dergelijke objecten gebruiken en hoe pas je deze toe? Een voorbeeld wordt gebruikt om deze vragen te beantwoorden.

Neem de bounded context van OrderManagement (fictief voorbeeld). Binnen deze bounded context is de Order de aggregate en deze heeft een collectie van OrderLine objecten. Het OrderLine object heeft informatie nodig over het Product. Product wordt in dit voorbeeld beschreven door een naam en SKU code. Stel nu dat deze eigenschappen als eenvoudige eigenschappen in de OrderLine worden ondergebracht. Niets weerhoud een onwetende ontwikkelaar ervan de productnaam aan te passen van de Orderline. Echter, dit is niet toegestaan omdat men zich kan voorstellen dat de naam en SKU code bij elkaar horen.

Om dit te voorkomen wordt Product gebruikt als value object. Indien het bestaande Product op de OrderLine aangepast dient te worden, dan passen we niet de eigenschappen van Product aan, maar vervangen we de huidige instantie van Product door een nieuwe instantie van Product.

In het laatste artikel welke na de zomervakantie zal verschijnen, wordt een case beschrijving gebruikt om alle beginselen die in de artikelen tot dusver aan bod zijn gekomen, te implementeren in een .Net solution.

Auteur: Arjen Kraak, Bergler Competence Center © 2018

Op 19 juni jongstleden organiseerde Bergler de thema-middag Domain Driven Design en (micro)services in de praktijk. We zien de afgelopen jaren steeds meer organisaties in meer of mindere mate agile werken, waarbij continuous integration en continuous deployment belangrijker worden. Om succesvol en snel aanpassingen in de markt te kunnen zetten is een behapbare en modulaire opzet van je software een must.

Tijdens deze sessie gingen we in op verschillende facetten om te komen tot modulaire software. We keken naar de basis principes van domain driven design en op welke manier je de boundries van de modules kunt bepalen. Verderop gingen we in op de effecten van een modulaire applicatie op je architectuur en als toonden we een aantal strategieen om van een bestaande legacy applicatie te komen tot een modulaire applicatie.

Vier sprekers zorgden voor een overvolle avond, de video’s kun je hieronder bekijken.

We zien steeds meer organisaties monolitische legacy applicaties ombouwen tot modulaire applicaties. Tijdens deze sessie gaan we in op de vraag waarom domain driven design je kan helpen bij het opzetten van losgekoppelde modules. Arjen Kraak introduceert DDD in gewoon nederlandse termen om met de aanwezigen dezelfde basiskennis te delen.

Tijdens deze sessie staan we stil bij Eventstorming en hoe je deze methodiek kunt toepassen om in korte tijd een domein in kaart te brengen en op kunt splitsen in modules. Patrick Bes vertelt over deze workshop-methodiek om op een snelle en leuke manier een business domein te analyseren om tot een DDD design te kunnen komen.

Tijdens deze sessie van Menno Jongerius gaan we in op een aantal basisprincipes achter domain driven design en hoe deze vertalen naar architectuur en losgekoppelde modules.

Sjaak Spiegels van Voogd & Voogd spreekt openhartig over de ervaringen bij het toepassen van DDD en presenteert de patronen van technieken die zij hebben toegepast.

En, heb je de smaak te pakken?

Meld je dan aan voor ons komende event op 13 november aanstaande: DevOps, continous delivery en distributed systems (Expertise Center). Nadere informatie volgt snel. Inschrijven kan via deze pagina.

Soms loop je in je zoektocht naar een framework of, zoals in dit geval bij toeval, tegen een framework aan waarvan je denkt: Ja, dit is leuk en handig om te gebruiken in mijn ontwikkel projecten. Bij mij was dat het geval toen ik per ongeluk tegen een cursus over het SpecsFor BDD framework aanliep tijdens het scannen van interessante cursussen op PluralSight).