Waarschuwing: wederom een lang verhaal! Mijn samenvatting van 7 sessies van Techorama, die per stuk ongeveer 1 uur duurden (met een enkele uitzondering).
12 oktober, 08:45 - 09:45, room 14, John Craddock, Issuing your own Microsoft Entra Verified Ids
Leuk, de tweede dag begin ik weer met een sessie van John Craddock!
Via Techzine (link) heb ik nog even gespiekt wat “Entra” ook alweer was, het is een groepering van Azure Active Directory, Permissions Management en Verified ID.
John laat ons zien hoe het huidige systeem werkt. Ik ga naar de basisschool (een tijd geleden), daar worden gegevens van je opgeslagen. Daarna Mavo, Havo-MBO, HEAO en HTS: elke organisatie heeft gegevens van mij opgeslagen. Als je dan aan het werk gaat: jouw werkgever slaat gegevens van jou op. Je opent een bankrekening: er worden gegevens van je opgeslagen. Dus op “tig plaatsen” staat informatie die eigenlijk “van jou” is.
We gaan nu kijken naar een andere flow, je hebt zelf de gegevens in bezit, de bank, school is een issuer en kan een verzoek doen. Via verifiers kun je jouw credentials delen (de verifier controleert of de issuer een vertrouwde partij is). Verifiers worden ook wel “relaying parties” genoemd.
In het echte leven gebeurt dat al. Als ik aangehouden wordt in mijn auto door een agent, toon ik mijn rijbewijs. Dit door de overheid uitgegeven document wordt vertrouwd door de agent.
In de digitale wereld worden issuers, holder en verifiers onderscheiden met een unieke Decentralized Identifier (DID). Voor elke DID wordt een private/public key-paar gegenereerd. The private key deel je nooit en houd je altijd in bezit. En die gebruik je om berichten te “signen”.
Een DID bestaat uit een unieke identifier en een DID document. Het document bevat de public key, service-endpoints en andere metadata. De endpoints kunnen een gelinkt domein en identity hub idenficeren.
Het DID docment kan gepubliceerd worden op een ledger met behulp van decentrale ledger technologie (DLT). Of gepubliceerd worden in de DNS domain namespace.
Microsoft ondersteunt op dit moment het Identity Overlay Network ION, DID start met did:ion:….
ION slaat het DID document op in een Interplanetary File System (IPFS).
DID documenten in een batch worden “geanchored” in de Bitcoin blockchain.
Microsoft ondersteunt ook did:web
Het DID document wordt opgehaald via de DNS domain namespace.
We krijgen nog een lijst met Decentalized Identifiers:
did:method:method-specific-identifier
- Bitcoin btcr
- Blockstack stack
- Etherium:uport uport
- Sovrin sov
- Bitcoin (+ Sidetree) ion (Indentity Overlay Network)
- DNS namespace web
En een DID document, waar dit uit bestaat:
- DID
- Public keys for verification
- Authentication methods
- Service endpoints
- Timestamp
- Signature
did:web
DID document opgeslagen in DNS domain namespace
Formaat is did:web:domain-name
bijvoorbeeld: did:web:hr.xtshub.com
Als alleen de domeinnaam gespecificeerd is, dan ga je naar /.well-known/did.json
Je kunt ook een pad en/of een poortnummer mee te geven.
Je hebt 2 soorten DIDs, de korte versie, maar ook de lange versie.
Hierbij zit het DID document “er bij in”. BASE64 JSON meende ik.
Toekomstmuziek: universele DID resolvers.
Je hebt en Entity, die doet een query voor did:methode:methode-specifieke-identifier.
Die call gaat naar Universal DID resolver, die gaat dieper naar Method driver did:ion (ION zit in blockchain vastgezet), naar method driver did:btcr (rechtstreeks blockchain), did:web of andere drivers.
De Microsoft resolver werkt zoals we zagen nu alleen nog met did:ion en did:web.
ION Explorer is beschikbaar op https://identity.foundation/ion/explorer
En het voorbeeld naar de online did.json op het domein van John: beta.discover.did.microsoft.com/1.0/identifiers/did:web:hr.xtshub.com
John toont nog de DNS Binding.
Hij heeft de URL https://masterclass.xtshub.com/.well-known/did-configuration.json
Hiermee link je een DID aan een enity domeinnaam via DNS.
De DID kan hiermee geverifieerd worden als “horende bij die entiteit”.
Microsoft Entra Verified ID.
Services voor het uitgeven en controleren van credentials.
De Microsoft Authenticator houdt deze vast.
- uitgegeven credentials kunnen getoond worden voor verificatie.
Integreert met Azure Active Directory.
Er veranderen heel veel dingen!
De apps voor het uitgeven en presenteren hadden zware rekencapaciteit nodig.
Dat wordt nu gedaan door de Verifiable Credentials Service Request API.
Een VC (Virtual Credential) wordt gedefinieerd door een display en rule definition bestand.
- Deze werden in een Azure Storage opgeslagen.
- Display: kleur, tekst en claims.
- Rules: details hoe je de claims kunt ophalen.
De definities worden nu rechtstreeks door de Verified ID service opgeslagen.
Om het te snappen zul je er zelf mee aan de slag moeten gaan. Dat kan.
Code samples voor de issuer en de verifier app zijn beschikbaar op Github: aka.ms/vcsample
En je kunt ook de blogs van John volgen: www.xtseminars.co.uk/blog
Dan is er nog een blok “credential revocation”. Want het is wel fijn dat je na de tijd ook nog zaken ongedaan kunt maken.
Een claim in de VC kan gemarkeerd worden als indexed.
- de VC status kan op revoked gezet worden gebaseerd op de geindexeerde claim.
De Microsoft status check is gebaseerd op het Status List 2021 W3C voorstel.
Status list 2021:
- hoge compressie, bit string gebaseerde status lijstformaat
- behoud van privacy
De status list wordt opgeslagen in de identity hub van de tenant.
Dat deze zaken “overal moeten werken”, dat is duidelijk voor zo’n product.
Het is gebaseerd op JWT VC Presentation Profile: link.
Oproep om je hierbij aan te sluiten om te zorgen dat er goede VC’s in je eigen sector beschikbaar komen. Sluit je aan bij de Decentralized Identity Foundation (DIF) en begin in je eigen bedrijf rond te vragen hoe collega’s andere afdelingen het gebruik van VC’s zien.
Coming soon: Entitlement Management via VC
12 oktober, 10:00 - 11:00, room 7, Eduard Keilholz, Kubernetes made easy - Getting the hang of Azure Container Apps
Ik heb eerder een sessie van Eduard gezien (Eduard werkt bij 4dotnet) en dat was een prima presentatie, dus ik ga er vanuit dat ook deze dag de presentatie boeiend is. Ook over een onderwerp waar ik wel redelijk wat over gehoord heb, maar zelf nog niet echt iets mee gedaan. Een docker image via Docker Desktop en nog ergens een Docker-omgeving opgezet.
Je hebt in Azure de Azure Kubernetes Service. Maar dat heeft nogal een flinke leercurve. Als alternatief heb je in Azure nu ook Azure Container Apps. Je hebt daarbij niet alle mogelijkheden beschikbaar, maar wel de meest gangbare opties.
Eduard heeft een omgeving opgezet waarmee hij ons kan laten stemmen (een online poll dus). Of we al wat met Kubernetes gedaan hebben en dergelijke. Alleen… het werkt niet. Je maakt een keuze, klikt op de knop en er gebeurt niets.
Ik vermoed dat dit met opzet gedaan is, want zo kan Eduard ons laten zien hoe je via Live Metrics kunt zien “dat er iets aan de hand is”. De kolom met Dependency Call Failure Rate loopt op en in de lijst van Sample Telemetry zien we in het rood meldingen, the specified recourse does not exist.
De pollstar-projecten zijn terug te vinden op de Github van Eduard: link. De handigste manier is om te zoeken: directe-link.
De kosten van een container zijn 25 euro per maand, als je er 10 hebt draaien dan is dat dus 250 euro. Als er niets uitgevoerd wordt hoef je ook niets te betalen.
Binnen een container omgeving kun je meerdere apps provisionen. Je hebt verschillende versies, de “single revisionmode”, waarmee je 1 versie van je app hebt, of de “multiple revisionmode” waarbij je meerdere versies naast elkaar kunt laten draaien.
Met Ingress (reverse proxy) kun je verkeer inregelen, dat het gelimiteerd blijft tot container apps, binnen een VNet blijft (intern dus) of dat het “from anywhere” bereikbaar is.
Container Apps Secrets, scope is de applicatie. Als je secrets voor container apps hebt kun je dat via Azure Keyvault doen. Voordeel is dat als je secrets wijzigen je geen nieuwe revisie hoeft te maken.
DAPR voor micro-services, KEDA voor event driven autoscaling. Container Apps hebben alleen de defaults, dus de KEDA scaledjobs zijn niet beschikbaar.
Er komen nog een aantal vragen uit het publiek. Zo vraagt iemand of je de containers met Let’s Encrypt kunt laten werken: heeft Eduard voor deze demo niets mee gedaan, dus onbekend.
Na de tijd bij de stand van 4dotnet krijg ik van Eduard zijn boek “Azure Infrastructure as Code”.
Bij het bekijken van de tweets zie ik een aantal prijswinnaars bij de stand van 4dotnet en zo wordt daar ook Barbara genoemd. Ik ken haar niet, maar ze heeft zo te zien een interessante blog over Azure!: link.
12 oktober, 11:30 - 12:30, room 8, Jakob Ehn, From 0 to 60 with Azure Kubernetes Service
Deze sessie sluit mooi aan op de voorgaande, was dat de Azure Container Apps, nu gaan we meer de diepte in: Azure Kubernetes Service door Jakob Ehn.
Eerste tip van Jakob: als je een IT-boek schrijft neem dan nooit een jaartal mee in je titel! We zien het boek Continuous Delivery with Visual Studio ALM 2015 en dan denk je inderdaad al gauw: is dat 7 jaar oud? Dat zal vast niet meer actueel zijn…
We zien een schema wat Jakob gemaakt heeft, het K8S (Kubernetes) cluster met 3 containers: QuizBox Web, QuizBox API en QuizBox SQL. Binnen het blok zit een autoscaler en Ingress. Ingress zorgt voor communicatie naar binnen en buiten naar onder andere Lets Encrypt en Azure Container Registry. De Azure Load balancer ervoor, serverless scaling via Azure Container Instance. En nog inkomend verkeer via CI/CD, de pipelines.
We zien de .yaml-bestanden. Jakob heeft zelf een batch-bestand gemaakt zodat hij niet continue de “lange syntax (kubectl)” hoeft te gebruiken, hij kan het nu via een k get deploy frontend, k get svc frontend en k get deploy frontend.
We zien hoe het aantal replica’s ingesteld kan worden.
En als je er zelf mee aan de slag wilt gaan, dat kan. De code staat op Github: link.
En Jakob noemde ook nog “virtual kubelets”, die kun je in deze Github vinden: https://github.com/virtual-kubelet
Jakob wil de autoscaling laten zien (k autoscale) en moet dus “load” genereren. Hiervoor gebruikt hij bombardier: https://github.com/codesenberg/bombardier
12 oktober, 12:40 - 13:00, partner stage, Michiel Doeven, State Management with Flux
In Javascript hebt je React, Angular. Maar je hebt ook Blazor waarmee je in C# kunt werken. Bij React heb je Redux en bij Angular heb je NrRx voo Flux patterns. Fluxor is een state-management bibliotheek gebaseerd op Flux voor Blazor.
Michiel Doeven van ShareValueNL toont ons eerst een schema van Flux. Een gebruiker doet iets, wat een Actie verzend / dispatches. Reducer reageert op verschillende Acties en werkt de Store bij. De View luistert naar het wijzigen van de State en dat gaat weer terug naar een mogelijke Actie.
Michiel toont ons een demo, hij heeft een applicatie gemaakt die gegevens uitleest via de API van de RDW (Rijksdienst voor het Wegverkeer) waarmee je gegevens over kentekens uit kunt lezen.
Via Github kun je het project zelf openen en bekijken: link.
En als je zelf leuke dingen met de data van RDW wilt doen: https://opendata.rdw.nl/
12 oktober, 13:45 - 14:45, room 14, Laila Bougria, Message processing failed! But what's the root cause?
Ik zou eigenlijk naar Christos Matskas zijn sessie “Automate your identity infrastructure with .NET Notebooks and MS Graph”, maar die sessie is vervallen. Dus even rondgelopen om te kijken wat een goede vervangende presentatie zou zijn.
Dat leek mij deze wel, want als we straks steeds meer naar micro-services gaan, alles steeds meer “ontkoppeld” is en er gaat wat fout: hoe ga je dan debuggen/de oorzaak opsporen?
Laila Bougria werkt bij Particular Software. Ze gaat met ons door een voorbeeld van een e-commerce website. Daar werken 3 teams aan, omdat we met micro-services werken kunnen deze redelijk “los” van elkaar ontwikkelen. Team Lorem, team Ipsum en team Dolor (wat schijnbaar staat voor pijn: er is altijd een team wat tegen de shit aan gaat lopen). We zien de verschillende berichten die over de lijn gaan, placeorder, chargeorder, updatestock, orderpackaged, orderbilled, verifycustomerstatus.
Omdat het “autonome componenten” zijn wordt er op basis van contracten met elkaar gewerkt.
Dan toont Laila ons de foutmelding die naar voren komt, Immediate Retry is going to retry message ‘GUID’ because of an exception: … sequence contains no matching element … UpdateProductStockHandler.cs: line 14.
Hoe ga je een gedistribueerd systeem “debuggen”?
De volledige oplossing inladen en via F11 stap-voor-stap doorlopen?
Zijn je collega’s ook bezig om orders aan te maken in de test-database?
Het woord wat we zoeken is: TEST
We breiden het AAA-principe uit (eerder bij onze unit-testen sessie voorbij gekomen):
- Arrange: prepare message
- Act: invoke the message handler
- Assert: desired outcome in any data modifications
Maar… bij assert moeten óók je outgoing messages beschikbaar zijn.
Want dan kun je zien “wat” het systeem verlaat.
Tevens noemt Laila “what about the order”? Wij denken sequentieel, maar als op 1 of andere manier de flow van de interacties wijzigt, dat kan ook invloed hebben op het resultaat.
Als je het verkeer/data wilt debuggen kun je gebruik maken van distributed tracing. Daar zijn veel tools en frameworks voor, zijn leverancier-specifiek, dus ontstond de behoefte om met standaarden te komen.
Laila komt met OpenTeleMetry. Het is een observability framework, open souce en levert tools, API’s en SDK’s. Het kan telemetrieke data verzamelen en exporteren. Het is cross-platform en cross-runtime.
Met observability heb je inzicht in de “interne werking”, kun je de expected en unexpected system state zien, hiervoor hoef je geen code aan te passen en je kunt ook externe tools gebruiken.
Het bestaat uit meerdere delen, tracing, maar ook logging en metrics.
Hierna volgt de uitleg van wat zaken betekenen;
Trace: hiermee “track” je de progressie van een request. Het is een Tree of spans. En een span, dat is een “unit of work” in de trace en heeft een context.
We zien een mooi overzicht met blokjes hoe een order door het systeem gaat.
Klik je zo’n blokje aan, dan krijg je extra informatie (die je volgens mij wel zelf moet registreren?), zoals het order ID, het bedrag, betaalmethode en meer.
Hoe wordt een distributed trace gebouwd?
Het wordt gepropageerd via standaard protocollen.
W3C heeft een Trace Context voor http headers uitgewerkt.
We zien het voorbeeld van aa-bbbbbbbbb-cccc-01, waarbij aa de versie is, bbb de trace-id en cc de span-id.
Hoe gaan we hiermee starten?
Nou, het zit al in .NET. Via de System.Diagnostics.API. Er is een System.Diagnostics.DiagnosticsSource nuget-package. Tijd om hiermee bronnen te selecteren en starten om data te verzamelen.
Dan het overzicht van Exporters en Tools. Dat zijn er een hele hoop!
Azure Monitor, DataDog, h, Splunk, Jaeger, ZIPKIN, Prometheus en New Relic.
OpenTelemetry ondersteuning zit ook in veel onderdelen. Http Client, SQL Client, Azure SDK, AWS, ASP.NET Core, Entity Framework Core, gRPC, Redis, NServiceBus.
Bij Microsoft zijn wel een paar zaken anders genoemd. Als je dat weet zou dat voldoende moeten zijn. Zo is Tracer – ActivitySource, Span – Activity en SpanContext is ActivityContext.
Een ActivitySource geef je een unieke naam. Je hebt er 1 per subcomponent.
Wat gaan we met logging doen? Advies is om traces “high level” te houden. Je wilt niet te veel data daarin opslaan. De details kun je wel loggen. Vervolgens moet je de traces en logs aan elkaar kunnen koppelen. Zo zien we dat in het LogRecord nu ook een TraceId en SpanId opgeslagen worden.
En de metrieken. Dat zijn scalar values opgeteld over een periode van tijd. Het kan een basis zijn voor alarmeringen. Je kunt op basis van de metrieken verwachtingen opstellen: over 2 weken loopt een schijf vol, we moeten wat doen. Het kan een indicatie zijn van “een” probleem.
Wat zijn de nadelen?
- Allocatie, zaken moeten ingericht worden.
- Network usage, er gaat (wat) meer verkeer over de lijn.
- Storage, de data moet ergens opgeslagen worden.
- New tools, daar zullen de gebruikers mee moeten leren werken.
- En het moet onderhouden worden. Updates, security-patches.
Extra voordelen zijn dat je fouten kunt onderzoeken. En ook dat je post-mortems kunt onderzoeken (het systeem lag toen plat, werkt nu weer prima, wat was er toen aan de hand dan?). En je kunt feature flagging toevoegen: met die optie actief ronden gebruikers hun bestelflow 10 seconden sneller af. Chaos Engineering: hoe zeker ben je dat het systeem blijft draaien na nieuwe features? Goede omschrijving daarvan is hier te vinden: link.
Samenvatting, observability is cruciaal, onderzoek welke telemetrie voor jou nuttig kan zijn, verbind dit met je bestaande logs/logging en breidt dit uit/zorg dat de resultaten een mooie toevoeging zijn op de werking van “het systeem”.
Op de Github van Laila kun je het C# project vinden en ook meer informatie: link.
12 oktober, 15:00 - 16:00, room 13, Edwin van Wijk, How to get a grip on your microservices system using a service-mesh
Een mooie aanvulling op de vorige sessie die gevolgd heb over “problemen bij micro-services, hoe gaan we dit oplossen”, in dit uur laat Edwin van Wijk van InfoSupport zien hoe je met een service-mesh je micro-services in Kubernetes kunt monitoren (en meer).
Omdat micro-services flexibel zijn moet je op een gecontroleerde manier die services kunnen draaien. Containers, DevOps, infra as code en service mesh.
Een service mesh is een infrastructuur-laag die service-to-service verkeer over een netwerk beheert. Een service mesh biedt deze extra’s:
- Security
- Traffic shaping and intelligente routering
- DevOps: observability, A/B testing, Canary Release
- Retries / Circuit Breakers (ik hoor dat Edwin hier Polly noemt, dat gebruik ik zelf ook)
We zien de “pods”, die binnen Kubernetes de containers bevatten. Je kunt in zo’n pod een Sidecar Container toevoegen, die als proxy gaat acteren. Het verkeer naar binnen en buiten loopt dan via die proxy en daardoor krijg/heb je er invloed op.
Er zijn verschillende implementaties. Edwin noemt Linkerd, Consul, Open Service Mesh, nginx service mesh en Istio. Istio is een betaalde variant die Edwin zelf vaak gebruikt en ook in de demo laat zien.
Istio is een complete service mesh implementatie.
Gebouwd met verschillende open-source tools zoals Envoy, Mixer, Pilot, Citadel, Prometheus, Grafana, Kiali en meer.
Het voegt aan Kubernetes een set CRD’s toe (Custom Resource Definitions).
En het ondersteunt meerdere protocollen: http, gRPC, WebSocket en TCP.
Istio biedt logging, tracing en monitoring. Grafana, Kiali, Jaeger en Prometheus zijn standaard beschikbaar.
We zien een manifest-bestand voor Kubernetes en hoe daar Istio in “geïnjecteerd” wordt:
istioctl kube-inject
Automatische “injection” is ook mogelijk. Daarmee zorg je dat tijdens het deployment naar Kubernetes Istio automatisch toegevoegd wordt. Dat doe je door een “annotation” in het manifest toe te voegen:
template:
metadata:
labels:
app: workshopmanagementapi
version: “1.0”
annotations:
sidecar.istio.io/inject:"true"
Edwin heeft een demo met een simpele autogarage, voor reparaties. Je hebt customer management (klanten beheren), vehicle management (voertuigen beheren) en de workshop management (planning, onderhoudstaak, klant en voertuig).
We zien in het overzicht hoe Edwin tussen de API’s en de services RabbitMQ heeft zitten.
Supercool om in Kiali de “flow van data” te kunnen zien. Ook “indirect” uitgaand verkeer kan getoond worden.
Je kunt de stabiliteit van het systeem testen. Zo stelt Edwin in dat 25% van het verkeer een 500-status error krijgt.
Mocht je de code van de demo willen zien, deze is op Github op te vragen: link.
12 oktober, 16:30 - 17:30, room 12, Bart de Smet, Adding a new Language Feature to C# in 60 minutes
Daar was Bart de Smet weer. Gisteren liet hij zien wat er mogelijk is in C#10 en C#11, vandaag gaat hij laten zien hoe we via Roslyn een nieuwe language feature toe kunnen voegen aan Roslyn. Een beetje inception dus!
Bart laat zien hoe er een “InExpression” toegevoegd kan worden. Een kwestie van zaken toevoegen in XML-bestanden en in CS-bestanden. Bart heeft de boel ingecheckt in deze branch op Github, dus je kunt zelf bekijken wat hij heeft gedaan: link.
Tijdens het zoeken zag ik dat er op 10 oktober nog workshops geweest zijn (had ik al gelezen), maar ook dat Bart een sessie gedaan heeft: link.
Mocht je dat zelf thuis ook nog eens willen doen, hier de stappen zoals die hier op de site staan (mogelijk wordt dit er later afgehaald):
Prereqs:
Installation of Visual Studio 2022 with .NET workload enabled.
Visual Studio 2022 IDE - Programming Tool for Software Developers (microsoft.com): link.
Installation of Git.
Git - Downloads (git-scm.com): link.
GitHub account.
GitHub: link.
Fork Roslyn repo.
Fork dotnet/roslyn (github.com): link.
Git clone and build forked repo.
mkdir %USERPROFILE%\source\repos
cd %USERPROFILE%\source\repos
git clone https://github.com/xyz/roslyn.git (replacewith your GitHub user name)
cd roslyn
restore.cmd
build.cmd
Install .NET 7 RC1 SDK
Download .NET 7.0 (Linux, macOS, and Windows) (microsoft.com): link.
Install ILSpy
ILSpy - Microsoft Store Apps: link.
En daarmee is deze dag voor mij “ten einde”. Er kwam nog een sessie maar “The Innovation Ninja” klonk een beetje zweverig. Techorama was fantastisch!