Bekijk hier het webinar van het Bergler Competence Center (Building Async Apps). (55 minuten).
Abonneer je op ons YouTube-kanaal, dan blijf je altijd op de hoogte!
Meer informatie over onze andere evenementen lees je hier.
Tijdens deze avond op 25 juni jl. stonden we stil bij deze ontwikkeling en hoe je stappen kunt zetten om je applicaties voor te bereiden op .NET Core. We gingen in op de positionering van .NET Core ten opzichte van Xamarin en .NET Standard en gaven aan welke technologie wanneer toepasbaar is.
Met de opkomst van allerlei verschillende apparaten, is het voor aanbieders van applicaties best een uitdaging om te bepalen welke technologie het beste past bij hun applicatie. Sommige organisaties kiezen voor responsive webapplicaties, veelal gebruik makend van een single page framework, anderen kiezen voor native applicaties. Een webapplicatie biedt de mogelijkheid om met één code base te werken en is eenvoudig te onderhouden, maar draait in de sandbox van de browser en is dus gelimiteerd in de mogelijkheden tot wat een browser ondersteunt. Een native app heeft betere performance en kan alle mogelijkheden van het besturingssysteem benutten, maar is lastig te onderhouden en code hergebruiken is slechts gedeeltelijk mogelijk.
Voor organisaties die kiezen voor een webapplicatie, maar toch dichter tegen de beleving van een app willen kruipen, biedt de progressive web app mogelijkheden. Een progressive web app, draait in de browser, maar in de belevenis van de gebruiker wordt deze ‘geïnstalleerd’.
Wat kun je doen met een progressive web app
Een progressive web app biedt alle mogelijkheden van een moderne browser en dat is momenteel behoorlijk veel. Zo kun je gebruik maken van verschillende local storage mechanismes, diverse api’s voor bijvoorbeeld locatie bepaling en push notifications (op dit moment alleen in android en windows). Daarnaast worden de bestanden van een progressive web app lokaal in de browser opgeslagen waardoor de app offline kan draaien.
Wat is nodig voor een progressive web app
Het is belangrijk dat de webapplicatie als één applicatie kan draaien. In de meeste gevallen betekend dit dat het een single page application is die met een API backend communiceert. Daarnaast moet je de volgende zaken inregelen:
Het manifest is niet veel meer dan een metadatabestand dat de browser vertelt wat voor een applicatie geïnstalleerd wordt:
Om de service worker toe te voegen zijn voor de meeste frameworks packages beschikbaar die een service worker genereren:
Vervolgens stel je de configuratie in van de service worker:
In dit voorbeeld zie je dat de index.html en alle js en css bestanden lokaal opgeslagen worden.
Als laatste definieer je een build waarin de service worker gegenereerd wordt:
Wil je meer weten over service workers en progressive web apps? Google heeft een uitgebreide tutorial beschikbaar: https://developers.google.com/web/ilt/pwa/introduction-to-service-worker
Wanneer gebruik je een native app
Voor meer informatie en voorbeeldcode in angular kun je kijken op: https://scotch.io/tutorials/how-to-build-progressive-web-apps-with-angular
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.
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.
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
Door: Patrick Bes & Chaim Zonnenberg
De overstap naar een nieuw software landschap
Verouderde software… welke ontwikkelaar heeft er geen ervaring mee? Jarenlang heeft je bedrijf functionaliteit ontwikkeld in dezelfde applicatie.
De oorspronkelijke ontwikkelaars van de applicatie zijn al lang geleden vertrokken. In de loop der tijd is in de code van alles aan elkaar geknoopt.
Het gevolg: het proces neemt vier keer zoveel tijd in beslag , kost steeds meer en levert steeds minder releases op. Een grote legacy applicatie ontstaat, oftewel: een monoliet, een “Big Ball of Mud”.
Tijd voor iets nieuws? Het vervangen van een legacy applicatie is een uitdaging. Het is de trend om een monoliet te vervangen door een microservices landschap in de cloud. Dit biedt voordelen als snel releasen, snelle feedback en makkelijk experimenteren met nieuwe features. Maar hoe migreer je nu zo’n Big Ball of Mud naar een Microservices landschap?
Big-bang migratiestrategie
We horen regelmatig dat een ontwikkelteam het migreren naar een microservice landschap complex vindt. Het omgaan met afhankelijkheden, het overzetten van de aanwezige data en vaak ook de security, maken dit tot een complexe operatie. Daarom kiezen organisaties ervoor om alles in één big bang over te zetten: eerst een compleet nieuw landschap ontwikkelen om veel later – wanneer het nieuw ontwikkelde beter is dan de legacy applicatie – in één keer over te stappen. Aan deze strategie zit een groot nadeel vast: je investeert zonder direct rendement. In de praktijk ben je dan vooral de oude applicatie aan het nabouwen. Doordat er geen productie-feedback is, vindt er nauwelijks echte vernieuwing plaats in je applicatie.
Stap-voor-stap migratie
Toch is het mogelijk om stap-voor-stap over te gaan. Dit vereist een heldere blik op de doelarchitectuur waarbij je voorkomt dat legacy elementen vermengd raken met de nieuwe microservices wereld. Ook is een goed plan nodig waarin pijnpunten en risico’s goed in kaart gebracht zijn. Op het vlak van Security is het belangrijk dat tijdens de migratieperiode een eindgebruiker toegang krijgt zonder onderlinge obstructies tussen de monoliet en de microservices. Door de onderlinge uitwisseling van toegangstokens ondervindt de eindgebruiker geen hinder van het wisselen tussen die twee omgevingen.
In deze blog
Met deze blog geven wij een overzicht van de verschillende opties voor een migratie scenario. Dit is het eerste van drie artikelen waarbij wij inzoomen op de aandachtspunten en implementatie keuzes. In het volgende deel ligt de focus meer op keuzes voor het te gebruiken protocol. We sluiten af met een aantal voorbeeld scenario’s en codevoorbeelden.
Keuzes
SAAS or not to SAAS?
De titel van de blog serie geeft aan dat wij ons focussen op het gebruik van IdentityServer4. Maar waarom kiezen wij niet voor een SaaS oplossing als Auth0, OKTA of Azure AD? Wij hanteren als uitgangspunt de migratie van een monoliet naar een microservices model waarbij beide omgevingen tijdens dit proces naast elkaar beschikbaar blijven. Dit impliceert de uitwisseling van toegangstokens tussen beide omgevingen. Het is in veel gevallen een gegeven dat een legacy applicatie zoals onze monoliet een On-premise datastore gebruikt met hierin de credentials van de gebruikers. Deze zijn vaak niet of moeilijk te verplaatsen naar de datastore van een SaaS oplossing. Wachtwoorden zijn meestal met een hash opgeslagen en hierdoor per definitie niet meer te ontsleutelen. Het migreren van deze credentials naar een SaaS datastore betekent dat alle gebruikers een nieuw wachtwoord krijgen. Dat is niet altijd wenselijk. Daarnaast is het vaak niet toegestaan om gebruikers credentials in de cloud op te slaan door regelgeving. Op basis van deze randvoorwaarden is IdentityServer4 een voor de hand liggende keuze. Vooral omdat IdentityService4 in de basis een set aan opensource nuget libraries biedt en wij hierdoor veel vrijheid op het gebied van implementatie en hosting krijgen.
Rol SSO-microservice
In het vervolg van deze blog gaan we er vanuit dat er in het nieuwe landschap één centrale SSO-microservice is. Deze SSO-microservice geeft tokens uit voor autorisatie op API’s. Daarnaast biedt het de mogelijkheid om in te loggen op je clients. Sterker nog: SSO is één van de randvoorwaarden voor het begin van een microservice architectuur. Een gefaseerde invoering van nieuwe microservices in combinatie met een SSO oplossing verloopt dan als volgt:
1. Zorg voor een centraal component voor authenticatie en autorisatie.
2. Faciliteer het federeren tussen monoliet en SSO microservice.
3. Benut de SSO Microservice als centraal inlogpunt. De monoliet gebruikt deze dan ook.
Claim mapping
Het security model van de monoliet is vaak gebaseerd op oude security principes: bijvoorbeeld names en roles. Een microservice landschap werkt meestal met claims en scopes. Gebruik een Anti-Corruption-Layer (ACL) om de wereld van de monoliet en het microservice landschap gescheiden te houden. Vertaal de credentials van de ene naar de andere wereld via een claim mapping. Voorkom dat details uit het security model van de monoliet zich vermengen met het nieuwe security model. Want als iets eenmaal in het nieuwe security model zit, raakt het niet snel weer kwijt.
Veiligheid voor alles
Hoe blijft het hele applicatielandschap veilig tijdens de migratie? Hou rekening met de volgende zaken:
Voorkom zelfbouw
Custom security code zorgt voor veiligheidslekken, zeker als veel verschillende ontwikkelaars aan de dezelfde broncode werken. De geschiedenis wijst uit dat bestaande monolieten vaak bol staan van custom security code. De introductie van een SSO-microservice biedt een goede gelegenheid om deze code uit te faseren. Introduceer in ieder geval geen nieuwe custom code.
Uitloggen niet vergeten
In het kader “veiligheid voor alles” is uitloggen ook een belangrijk onderwerp. Dit klinkt als een open deur, maar is toch relevant. Het gebruik van standaard protocollen ondersteunt het uitloggen. Hou tijdens de migratie rekening met testscenario’s die uitloggen op alle verschillende onderdelen van het landschap (dus uitloggen op de monoliet en op de microservice). Controleer ook altijd of beide onderdelen zijn uitgelogd.
Standaard security protocollen/specificaties
Kijk bij de ontwikkeling een federatie scenario tussen een legacy monoliet en de nieuwe SSO microservice als eerste welke protocollen en/of specificaties de monoliet ondersteunt. Wellicht is het mogelijk om WS-fed of SAML te gebruiken. Het is dan aan te raden om een keuze te maken voor een degelijke specificatie, boven de introductie van een zelf ontwikkelde uitwisseling van gegevens.
Het vervolg
De volgende stap is de keuze voor het uitwisselingsprotocol tussen de monoliet en de microservices. De mogelijkheden zijn ondermeer OpenID Connect, WSfederation of SAML. In de volgende blog gaan wij hier verder op in.
Auteurs: Patrick Bes & Chaim Zonnenberg, 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.
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:
| Yammer | Skype for Business/Lync | Teams | |
|---|---|---|---|
| Video conferencing | |||
| Audio conferencing | |||
| Instant messaging | |||
| Multiple channels | |||
| FileSharing | |||
| Screensharing | |||
| Mobile App | |||
| Call-in functions |
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.
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?
| Slack | Teams | |||||
|---|---|---|---|---|---|---|
| Free | Standard (€ 6,25) | Plus (€ 11,75) | Free | Office 365 Business Essentials (€ 5,--) | Office 365 Business Premium (€ 12, 50) | |
| Video conferencing | 1 op 1 | 15 max | 15 max | |||
| Audio conferencing | 1 op 1 | 15 max | 15 max | |||
| Instant messaging | ||||||
| Multiple channels | ||||||
| FileSharing | 5 Gb tptaa; | 10 Gb pp | 20 Gb pp | 2 Gb pp 10 Gb totaal | 1 Tb pp | 1 Tb pp |
| Screensharing | ||||||
| Mobile App | ||||||
| Call-in functions |
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.
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.
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.
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:
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:
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:
Welke winst hebben we nu geboekt:
Auteur: Menno Jongerius, Bergler Competence Center © 2018