Starters op de woningmarkt, een onderwerp dat regelmatig in het nieuws voorbij komt. Al een aantal jaar is de vraag naar woningen groter dan het aanbod, waardoor de prijzen flink zijn gestegen. Dit maakt dat het voor starters lastig is om zich in te kopen op de markt. Overbieden is tegenwoordig eerder de norm dan een uitzondering op de regel. Daarnaast zijn woning vaak al verkocht voordat je ze online hebt kunnen spotten, wat een aardige uitdaging is naast een 40urige werkweek. Kortom, voor een starter is het een hele uitdaging om de woningmarkt nauwlettend in de gaten te houden en er bovenop te zitten naast een fulltimebaan.

Als consultant op het gebied van datamonitoring en als nieuwkomer op de woningmarkt zag ik hier een kans voor een cool persoonlijk Splunk project. Mijn huizenjacht focuste zich op de woningmarkt in Rotterdam. Ondanks dat verschillende makelaars met ieder hun eigen aanbod en Funda al redelijk veel ondersteuning bieden, zat ik toch met verschillende vragen.

Wanneer komen nou de meeste huizen online? Welke huizen zijn vandaag online gekomen en in welke buurt? Ok, en voor deze buurt, wat is de gemiddelde vraagprijs? Is de vraagprijs voor deze woning aan de hoge kant? Wat is de m2 prijs?

Uiteindelijk heb ik mijn eigen monitoring dashboards gemaakt in Splunk, die mij net meer diepgang en inzicht kunnen geven in de Rotterdamse woningmarkt. Het is een ongoing project en graag presenteer ik in dit blog wat eerste resultaten. Daarna zal ik op bepaalde technische aspecten wat dieper ingaan. Qua data is alleen een geselecteerd aantal buurten en prijsklasse opgenomen die ik mogelijk interessant vond.

Dit dashboard geeft net zoals Funda in één oogopslag welke huizen er waar te koop zijn in Rotterdam. De single values tonen respectievelijk het totale aantal koopwoning (in mijn index), het aantal nieuwe koopwoningen vandaag, het aantal nieuwe koopwoningen gisteren, deze week, vorige week, twee weken geleden, drie weken geleden en ouder dan een maand. Verder kan er linksboven ook op specifieke buurten in de stad gefilterd worden, voor wanneer er alleen interesse is voor een bepaalde buurt. Op het eerste gezicht een heel eenvoudig dashboard. Maar door wat drilldown magic toe te passen kun je hier veel meer informatie uit halen.

Wanneer je bijvoorbeeld op de single value “vandaag” klikt, verandert het aantal pijlen en zie je waar welke woningen vandaag online zijn gekomen. Daarnaast verschijnt er onderaan ook een tabel met meer gegevens over deze nieuwe koopwoningen. Zo zie je naast het adres, de vraagprijs, prijs per m2, buurt/wijk en de publicatiedatum & tijdstip. Wanneer je liever op de kaart speurt, kun je ook op een pijl klikken en die geeft ook meer details van de koopwoning. Zie je een interessante woning en ben je nieuwsgierig naar de buurt, dan kun je nog verder ‘drillen’ naar een panel die gelijk de woning op Google Streetview laat zien. Zo zie je gelijk of de straat of woning je aanspreekt.

Dashboard 2: Woningmarkt Rotterdam statistieken

Dit dashboard presenteert statistieken van de Rotterdamse woningmarkt. Ideaal voor een nieuwkomer die nog niet bekend is met de huidige woningmarkt in zijn/haar stad. Het dashboard is momenteel nog vrij basic en bestaat uit vijf panels. In de toekomst gaat deze nog verder uitgebreid worden en krijgt deze een visuele upgrade.

Het eerste panel geeft antwoord op de vraag wanneer de meeste woningen online komen en in dit specifieke geval op Funda. Voor Rotterdam komen de meeste woningen blijkbaar ’s nachts rond 0:00 online. 

Het tweede panel presenteert hoeveel woningen er per wijk te koop zijn (geweest). Zo kun je zien in welke wijk de meeste woningen te koop komen. Op langer termijn kan dit nog uitgezet worden tegen de tijd, wat je bijvoorbeeld een indicatie kan geven wanneer in welke wijk de meeste woningen online komen. Of een trendlijn die kan laten zien of het aantal toe/afneemt.

De gemiddelde vraagprijs voor een woning per buurt verschilt en dit wordt weergegeven in het derde panel. Deze wordt berekend door de vraagprijs gedeeld door het aantal woningen per buurt. Deze zal over tijd nauwkeuriger worden wanneer er meer woningen in de index zitten. Hetzelfde geldt voor het panel daarna, waarin je per buurt kunt zien wat de gemiddelde m2 prijs is. Zo weet je dus in welke buurt de woningen relatief gezien het duurste zijn.

In het laatste panel is te zien welke hoeveelheid m2 woning het meeste aangeboden is tot nu toe in de index in dit project. Zo weet een nieuwkomer vrij snel wat de grootte van de meeste woningen zijn die in de verkoop komen.

De data voor dit project komt uit verschillende bronnen. Allereerst voor de gegevens omtrent de woningen die in de verkoop komen, wordt er gebruik gemaakt van de RSS feed van Funda. De RSS feed bevat de volgende gegevens: straatnaam, huisnummer, vraagprijs, oppervlakte en het aantal kamers. De feed kan precies met een aantal filters getweakt worden, zodat je alleen de woningen krijgt die jij interessant vindt. In dit geval heb ik gefilterd op een aantal buurten, stad en een prijsklasse.

Voor zowel Google Streetview en coördinaten is er een connectie gemaakt met twee API’s van Google Cloud, namelijk Geocoding API en Maps API. Dit kost nog geen halve euro per maand. In het eerste jaar kun je hier overigens gratis gebruik van maken. Echter om de juiste coördinaten op te vragen is er een straat, huisnummer en postcode nodig. De straat en huisnummer kan uit de RSS feed van Funda gehaald worden. 

Voor de gegevens omtrent postcode, buurt en gemeente, is er gebruik gemaakt van een aantal CSV’s van het CBS. Destijds was alleen de dataset uit 2019 beschikbaar. Het CBS biedt datasets aan met informatie over gemeenten, buurten, wijken en postcode van heel Nederland. Voor dit project zijn er 4 CSV’s samengevoegd tot een lookup tabel en gefilterd op de gemeente Rotterdam. Gezien sommige datasheets meer dan een miljoen regels bevatten (wat excel niet aan kan) is dit een ideale klus voor Splunk. In de volgend afbeelding is te zien wat de verschillende CSV’s waren en hoe deze zijn samengevoegd. 

Om uiteindelijk de data te kunnen gebruiken in Splunk is er gebruik gemaakt van de volgende Splunk apps: “Google Geocode app” en “Maps+ for Splunk”. Deze apps zijn beiden beschikbaar in Splunkbase. 

De Google Geocode App helpt je in het vertalen van een adres (straatnaam, huisnummer en postcode) naar Latitude en Longitude coördinaten. Aan de achterkant wordt de Geocoding API aangesproken in Google Cloud. De opgehaalde coördinaten worden samen met het adres, de oppervlakte, het aantal kamers, de vraagprijs, buurt, wijk en gemeenten opgeslagen in een summary index. 

Deze summary index wordt vervolgens gebruikt in de Maps+ for Splunk app. Hoewel er ook andere apps/add-ons zijn voor Google is er voor deze app gekozen gezien deze op stad/straat niveau de kaart kan weergeven. Daarnaast biedt deze app ook de functionaliteit om een Google Streetview panel te maken. Wat zoals eerder beschreven op een dashboard is geïmplementeerd. Dit panel maakt op de achtergrond een verbinding met de Maps API in Google Cloud. Deze geeft op basis van de coördinaten vervolgens op streetview een visualisatie weer.

Het is een ongoing project waar nog veel meer uitgehaald kan worden. Ik zie steeds weer andere mogelijkheden en heb verschillende ideeën. Qua dashboard, ben ik bezig met de Splunk Dashboard Beta app om Rotterdam nog beter te kunnen visualiseren en het dashboard naar een hoger niveau te tillen. Verder gezien ik op langer termijn meer data heb wil ik trendlines gaan toevoegen en mogelijk biedt machine learning nog bepaalde voorspellende mogelijkheden. Verder ben ik aan het onderzoeken of ik ook de actuele verkoopprijzen kan verkrijgen zodat je kunt gaan zien hoeveel er gemiddeld overboden wordt. De vraag is echter of deze data vrij te verkrijgen is. Er zullen vast nog andere toffe ideeën zijn. Mocht jij er een hebben, let me know! 

Hoe ik tijdens mijn huizenjacht met behulp van Splunk de Rotterdamse woningmarkt in kaart heb gebracht.

De Rotterdamse woningmarkt in kaart met behulp van Splunk

In de wondere wereld van frontend technieken zijn er nog zoveel dingen om nader te onderzoeken. In afwachting van mijn screening voor de opdracht bij de Politie besloot ik om een nieuwe website te maken voor CINQ. En nu – medio oktober – staat deze eindelijk live. In dit blog deel ik graag mijn ervaring over – met name – Next.js. Dat is namelijk precies waar je nu naar kijkt.

Na het zien van de eerste proof of concept raakte collega Marc Jacobs geïnteresseerd in mijn positieve wil. Samen besloten wij te brainstormen om tot een plan van aanpak te komen om toe te werken naar wat voor ons een succesvolle website zou zijn. 

Woorden als specialisten in Data, DevOps en Development vormen de basis voor ons verhaal, gevolgd door sociale IT’ers. Tijdens het ontwerpen en ontwikkelen van de website stond verschillende kenmerken constant centraal: de unit’s, events, vacatures en blogs. Ons doel was duidelijk.

Voor ik deze vraag ga beantwoorden is het interessant om te weten wat Next.js is. Zij omschrijven zichzelf als een React Framework voor Productie waarmee je met simpele handelingen een applicatie van A tot Z kan ontwikkelen en in productie kan zetten. Je krijgt hierbij toffe mogelijkheden, wat je kan zien als builts-in functionaliteiten, om een hybride en server side rendered applicatie te bouwen met minimale configuratie.

Dat klinkt als een kind kan de was doen, maar dan? Er waren redenen om de oude CINQ-website te vervangen, bijvoorbeeld dat deze niet makkelijk door onszelf was aan te passen, het op de mobiel beter kon werken en dat wij graag ons verhaal nog beter zouden willen vertellen. Wij hebben voldoende specialisten in huis om - ook voor onszelf - mooie dingen te ontwikkelen. Hoe mooi zou het dan zijn als wij zelf onze eigen website zouden ontwikkelen en onderhouden? Met deze voorkennis, natuurlijk ook in afweging van vele andere aspecten als bijvoorbeeld Next.js of NuxtJS, besloot ik om te kiezen voor Next.js in combinatie met Prismic CMS.

Toen ik eenmaal begon met het ontwikkelen van de website in Next.js was natuurlijk alles nieuw voor mij. Waar begin je dan? Gelukkig heeft Next.js een duidelijke documentatie. Om een snelle start te maken heb ik ervoor gekozen om te beginnen met een ‘bootstrap’ van Next.js via commando: 

Door de afgelopen jaren heen ben ik gewend om al in componenten te denken, omdat je dit bij alle frameworks wel op een bepaalde manier gebruikt. Waar je normaal vanuit een router pagina of module iets doet, heb je dit bij Next.js onder een folder pages. Bij de bootstrap installatie krijg je de onderstaande folder structuur.

├── pages             # folder voor alle pagina's
│   ├── api           # folder voor alle serverless functies
│   _app.js           # overal document voor je applicatie
│   index.js          # index.js verwijst naar / van de applicatie
├── public            # folder voor alle assets
├── styles            # folder voor styles
│   global.css        # globale style (voor bv. body tag)
│   Home.module.css   # module style voor homepage

Bij het ontwikkelen van een Next.js applicatie zijn er twee belangrijke folders, dit zijn pages en pages/api. In de folder pages zet je alle pagina’s die de applicatie kent. Je kan dit zien als een soort van router structuur. In de folder pages/api zet je alle API endpoints die je als Node.js serverless functie kan gebruiken. In de praktijk voor de CINQ-website hebben wij daarom pagina’s als bijvoorbeeld: pages/index.js, pages/contact.js pages/[uid].js en pages/blog/[id].js Deze pagina’s verwijzen naar de homepage (/), de contact pagina (/contact), een willekeurige content pagina waar geen andere pagina voor is (/data) en een blog artikel (/blog/toffe-developer-ervaring). Voor wat betreft de serverless API endpoints moet je denken aan het ophalen van meer artikelen voor de blogpagina of het versturen van het contactformulier.

Als je eenmaal een pagina hebt aangemaakt in de pages directory, dan is de volgende stap om data op te halen en componenten te gaan ontwikkelen. Voor het ophalen van data en de manier van renderen heeft Next.js verschillende implementaties. Met getStaticProps() kan je ervoor zorgen dat een pagina bij het builden van de applicatie wordt gemaakt, dit heet dan static site generation. Deze wordt dan voor elk request gebruikt. Daarnaast heb je ook een server-side rendered variant, dit gebruik je door de methode getServerSideProps(). De laatstgenoemde is wel langzamer dan de static variant, want deze doet bij elk request het opnieuw opbouwen van de pagina. Voor ons geldt voor de meeste pagina’s het laatste.

Mijn collega Marc wilde graag de website zelf kunnen beheren. Prismic is een Headless CMS dat uitstekend te combineren is het met het gebruik van Next.js. Je kunt in Prismic een aantal content types definiëren, dit resulteerde bijvoorbeeld in types als een blogpagina, een content pagina, een medewerker, een review of een vacaturepagina. Deze types werden er zo op gericht dat je dacht vanuit het componenten niveau wat wij in de applicatie kennen.

Om je een voorbeeld te geven hebben wij in Prismic een content pagina type. Stel wij hebben de pagina over Development. Deze bestaat nu uit een intro header, een intro content, kernwaarden met logo’s, vacatures en blogs. In Prismic heb ik het zo ingericht dat je deze blokken kan invullen, wijzigen van volgorde of het juist aanvullen van informatie met een tag. Zo zie je bij de vacatures alleen de vacature voor development, evenals bij de blogs dat je alleen de blogs zie over development. Kijk je naar de homepage zie je weer alle vacatures en blogs.

Wellicht vraag jij af hoe ik vervolgens de koppeling heb gelegd tussen Next.js en Prismic. Vanuit de Next.js pagina heb ik in getServerSideProps() een functie geschreven die de data ophaalt vanuit Prismic. Dit doe ik aan de hand van het type pagina. Nadat ik deze informatie heb opgehaald, stuur ik deze properties als JSON terug naar de pagina. Vervolgens laat ik door een soort van beslisboom de juiste componenten in de juiste volgorde zien. Dit betekent ook dat ik dus herbruikbare componenten heb ontwikkeld. Zo zijn componenten als bijvoorbeeld de intro tekst - in de code noem ik dit hero content- gebruikt voor de content pagina’s, maar ook voor pagina’s zoals dit blog artikel.

Samenvattend kom je steeds terug bij de kernwaarden die wij onszelf eerder hebben gesteld. Zowel bij de pagina’s, als de componenten als de inrichting van het Prismic CMS zie je deze terug. Hierdoor hebben wij een dynamische website, voorzien van herbruikbare componenten en slim gebruik van het CMS. Bij lange na heb ik natuurlijk niet alle toepassingen en keuzes over Next.js, Prismic of zelfs het in productie nemen via Vercel in dit blog kunnen toelichten. Mocht je naar aanleiding van dit blog een deep dive willen, dan kan je daarover altijd contact met mij opnemen via jeroen.burgers@cinqict.nl of via mijn Linkedin-profiel. 

Hoe maak je een succesvolle website of applicatie met Next.js en Prismic? Lees onze ervaring.

De nieuwe CINQ website: Geslaagde combinatie van Next.js met Prismic CMS

What are the goals of CI/CD, how can they be reached? A great variety of tools are used and often managed by a central CI/CD team who integrate, standardise and maintain them. As a CI/CD consultant, I have created numerous pipelines, but none of them was so complete and mature as the Auto DevOps pipelines templates from GitLab.

Join this webinar to see what CI/CD can do and take the next step in your DevOps journey.

CI/CD – from code to running in production

Sign up for our free webinar: the Benefits of CI/CD

Ik heb de afgelopen 2 jaar redelijk wat met Kubernetes gewerkt bij onze klanten en ondertussen is het uitgegroeid tot mijn favoriete (container/cloud) platform. In onze DevOps unit bij CINQ hebben wij aardig wat aandacht besteed aan Kubernetes met interne kennis-sessies, een reis naar KubeCon Europe '18 in Kopenhagen en ons eigen Kubernetes “bootcamp” in Friesland. 

👩‍🏫In twee dagen Kubernetes Advanced training, worden onze DevOps engineers klaargestoomd voor het KCA examen.

Dag 1 zit er bijna op, tijd voor de vrijmibo! 🍻

@container_solutions #kubernetes #containersolutions #joure #cinqict #work #prep #workshop #devops #cinq

Ik wilde graag mijn CKA (Certified Kubernetes Administrator) halen omdat ik in de breedste zin wilde weten hoe Kubernetes precies werkt, in plaats van alleen maar de nodige resources te gebruiken voor deployments. Denk hierbij aan de werking van de controlplane en het gebruiken van alle resources die Kubernetes tot je beschikking stelt. Dat zijn er namelijk nogal wat. Ook is het natuurlijk fijn om te weten dat je een bepaalde techniek beheerst.

Het CKA examen is een examen van 3 uur waar er van je verwacht wordt 24 problemen/vraagstukken op te lossen in verschillende Kubernetes clusters. Een score van 74% is vereist om te slagen. 

- EDIT oktober '20: Sinds kort duurt het examen 2 uur, waarin je 15 tot 20 problemen / vraagstukken op moet lossen en je een score van 66% moet halen om te slagen. Alle andere informatie in deze post is nog steeds relevant. - 

Ik heb het examen pas ingepland toen ik er van overtuigd was dat ik de tijd zou hebben om een paar weken achter elkaar te kunnen studeren en te oefenen. Zeker ook omdat ik meerdere malen heb gehoord dat het een pittig examen is waar je goed gebruik moet maken van je tijd. 

Op 5 juli heb ik mijn eerste examen gedaan. Ik had het gevoel goed voorbereid te zijn. Het examen kan je in je eigen huis/kantoor afnemen, waar je door een toezichthouder via de webcam en screensharing in de gaten wordt gehouden. Het online examen programma werkte prima. 

Ik twijfelde of ik het had gehaald na afloop, omdat mijn KubeADM vraag in de soep liep door een error van de cloudprovider (AWS). Achteraf heeft dit geen verschil gemaakt en is het misschien zelfs nog goed gerekend. Het resultaat kwam pas na 36 uur aan in de mail. Uiteindelijk heb ik toch een score van 91% behaald op mijn eerste poging.

Hoe kun je jezelf nou zo goed mogelijk voorbereiden voor het examen? En welke punten hebben extra aandacht nodig? Hieronder geef ik 10 tips waardoor ik het examen heb gehaald:

1. “Certified-kubernetes-administrator-with-practice-tests” 

Een alles omvattende cursus op Udemy door Mumshad Mannambeth. Zorg dat je de hele cursus hebt doorlopen en maak alle labs in Kodekloud. Alles wat in mijn examen werd gevraagd is behandeld in deze cursus.

Leer de kubectl commandline. Zorg dat je weet welk commando je waarvoor moet gebruiken, get, describe, logs, events, apply, etc.

Je mag de officiële Kubernetes documentatie erbij houden. Maak hier gebruik van door de cheatsheet erbij te pakken of snel te zoeken naar het onderwerp naar keuze.

Bouw een Kubernetes cluster handmatig vanaf de grond op. Alhoewel ik deze niet zo belangrijk vond als dat andere mensen die vonden, is het in ieder geval handig om het een keer te doen. Bovenstaande Udemy cursus heeft een guide om het op je eigen workstation met Vagrant en Virtualbox te doen. 

Bespaar jezelf wat tijd door de “imperative commands” te kunnen van simpele opdrachten. Denk aan: “kubectl run”, voor het deployen van simpele pods, of “kubectl expose” voor het aanmaken van een service die verwijst naar een bestaande pod. Dit zijn geen complexe opdrachten en zijn sneller uit te voeren op deze manier, in plaats van een YAML file te genereren of op zoek te gaan in de documentatie.

Zorg voor de complexere deployments dat je een YAML genereert, hergebruikt uit een eerdere opdracht of gebruikt vanuit de documentatie. Denk aan deployments met secrets of volumes. Gebruik hiervoor de voorbeelden in de documentatie en verander die naar wens.

Sla opdrachten over die je niet meteen weet, en maak deze later. Je hebt misschien de volle 3 uur nodig en elke punt is meegenomen. Vlag bepaalde vragen die je niet zeker weet om later op terug te komen.

Zorg dat je de Docker commando’s en concepten ook kent om te troubleshooten. Soms heb je geen kubectl tot je beschikking. Basic Linux kennis om te troubleshooten en opdrachten uit te voeren zoals: systemctl, nslookup, vi/vim, ps, ls, cp etc. 

Het gene waar CKA zich in onderscheid ten opzichte van CKAD is infrastructuur kennis. Zorg dat je gerelateerde opdrachten hieraan goed kunt maken. Denk aan ETCD backups, het gebruik van KubeADM, controlplane service configuratie en certificaten. Deze vragen zijn vaak veel punten waard en kosten meer tijd.

Controleer elke deployment of pods wanneer je deze hebt aangemaakt. Gebruik met de “get” of “describe” commands of jouw pods/deployments de juiste naam hebben, de juiste images gebruiken en überhaupt draaien en doen wat deze zouden moeten doen.

Met deze zorgvuldige voorbereiding en werkwijze tijdens het examen, heb ik het in één keer weten te halen. Heel veel succes met studeren en het examen, en als je vragen hebt - laat het weten in de comments of neem contact met ons op.

Met deze 10 tips ga je slagen voor je Certified Kubernetes Administroator examen.

10 tips voor het halen van je Certified Kubernetes Administrator examen

Sommige opdrachten kun je gewoon niet weigeren. Wij zijn gevraagd door de Rijksoverheid om te helpen bij het monitoren van de infrastructuur van de CoronaMelder app. Een uitdaging die we graag aan zijn gegaan!

We hebben hiervoor direct onze control room ingericht en inmiddels monitoren we live de performance van de CoronaMelder app.

De app wordt momenteel in een aantal GGD regio's in de praktijk getest, voordat deze straks landelijk wordt ingezet. Het doel van de app is om mogelijke besmettingen eerder te lokaliseren, zodat er eerder getest kan worden en verdere verspreiding wordt voorkomen.

Mooi dat we hier met CINQ een bijdrage aan kunnen leveren!

Meer informatie over de app vindt je op https://coronamelder.nl/

Sommige opdrachten kun je gewoon niet weigeren. Wij zijn gevraagd door de Rijksoverheid om te helpen bij het monitoren van de infrastructuur van de CoronaMelder app.

Monitoring inrichten voor de CoronaMelder app

In de afgelopen periode heeft zich een vrij nieuwe techniek zich aangediend genaamd WebAssembly. Wat kunnen wij ermee en wat zou het kunnen veranderen?

Vrij simpel gezegd is WebAssembly een techniek waarmee je in verschillende talen, dus niet vastgepind op één specifieke taal, iets voor de webbrowser kan ontwikkelen. Het is erop gericht om op een laagdrempelige manier de code te schrijven en hoogwaardige (native) gevoel te creëren. Daarnaast heeft het als doel om gecompileerd te kunnen worden tot een taal die de moderne webbrowser begrijpt. Niet als Javascript code, maar om hiernaast te kunnen draaien. Voorheen kon je alleen met Javascript een volwaardige ‘native’ webapplicatie voor de browser maken. 

WebAssembly kunnen wij zien als aanvulling op de Javascript code. Je kunt deze dan ook prima combineren om het beste uit beide werelden te halen. WebAssembly zegt een volwaardige oplossing te kunnen bieden voor een sterke performance. Wat hun sterk maakt is dat alle moderne browsers de techniek ondersteunen.

WebAssembly gebruik je om een webapplicatie voor de browser te ontwikkelen. Je kunt de componenten van je applicatie schrijven in diverse talen, waarna deze gecompileerd worden naar WebAssembly code. Door middel van de payload kan de browser het uiteindelijk via Javascript begrijpen. Belangrijk om te weten is dat WebAssembly een techniek is en geen nieuwe taal is. Het doet iets wat voor veel developers ongrijpbaar is. 

Met WebAssembly kan je grootschalige dingen als games of tekenprogramma’s bereiken. De vraag is alleen zijn wij al zover? Het geeft ons vandaag de dag wel al de mogelijkheid om bijvoorbeeld een complexe reken functionaliteit uit een andere taal als module over te nemen.

Aan elke techniek of code zitten voor- en nadelen, zo ook bij WebAssembly. Ten eerste geven zij aan geen vervanging te zijn voor Javascript. Zij zien de combinatie van bijvoorbeeld DOM manipulatie veel beter via Javascript gaan en bijvoorbeeld tijdelijk opslaan van data via WebAssembly. Het zou sneller en kleiner moeten zijn dan andere dingen. Volgens de makers zou je zelfs de gecompileerde code – wat zelfs voor Javascript lastig kan zijn – op een eenvoudige manier te debuggen is. De nadelen richten zich vooral op het feit dat het nog steeds geen native code zal zijn. Het voegt ook weinig toe voor de normale webapplicaties. 

Persoonlijk denk ik dat WebAssembly de wereld weer een extra mogelijkheid geeft. Ik zie vooral de voordelen in voor de zwaardere applicaties en niet voor meer ‘user friendly’ webapplicaties met wat data. Hiervoor is bijvoorbeeld de opstarttijd te zwaar, wat al snel weer als nadeel gezien kan worden. Daarnaast zie ik een vervanging van Javascript ook nog niet zo snel gebeuren. Hiervoor moet nog te veel gebeuren op allerlei vlakken. Javascript heeft zich al tientallen jaren bewezen als betrouwbare code voor het web. Kort gezegd geeft het ons weer nieuwe mogelijkheden en zal de toekomst, zoals wel vaker, gaan uitwijzen wat voor effect het heeft. Het zijn in elk geval mooie ontwikkelingen!

Verslaat WebAssembly het gewaardeerde JavaScript? Lees het blog op de CINQ website.

Verslaat WebAssembly het gewaardeerde JavaScript?

In this tutorial you can experiment with a local Kubernetes cluster that can be installed using VirtualBox or another virtualization product. This time we will use VirtualBox and Vagrant to set it all up. The Vagrant file will create one Kubernetes master server and two Kubernetes workers. A loadbalancer will also be created and will be used in our next blog about Traefik. After the installation we use Lens to connect to the created cluster. You must have a minimum of 16 GB of RAM for setting up this cluster.

To get started, make sure you download and install Vagrant, VirtualBox and Lens if you don’t already have them.
Vagrant
VirtualBox
Lens

First, we will install the boxes. In your terminal do the following:

vagrant box add ubuntu/bionic64
==> box: Loading metadata for box 'ubuntu/bionic64'
    box: URL: https://vagrantcloud.com/ubuntu/bionic64
This box can work with multiple providers! The providers that it
can work with are listed below. Please review the list and choose
the provider you will be working with.
 
1) hyperv
2) libvirt
3) virtualbox
4) vmware_desktop
 
# Choose 3) virtualbox


Getting the master, workers and loadbalancer.

git clone https://dennisvermeulen@bitbucket.org/dennisvermeulen/kubernetes-cluster.git

cd kubernetes-cluster/k8smaster
vagrant up
cd ../k8sworker1
vagrant up
cd ../k8sworker2
vagrant up
cd ../k8slb
vagrant up
cd ../k8smaster

vagrant ssh

vagrant@k8smaster:~$ sudo su -
root@k8smaster:~$ kubeadm init --config=kubeadm-config.yaml --upload-certs | tee kubeadm-init.out

Copy config file to communicate with the cluster

root@k8smaster:~$ mkdir -p $HOME/.
kuberoot@k8smaster:~$ sudo cp -i /etc/kubernetes/admin.conf 
$HOME/.kube/config
root@k8smaster:~$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

root@k8smaster:~$ kubectl create -f calico.yaml

root@k8smaster:~# kubectl -n kube-system get pods

NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-6b9d4c8765-p9wn7   1/1     Running   0          52s
calico-node-bgklp                          1/1     Running   0          52s
coredns-5644d7b6d9-fmbsb                   1/1     Running   0          71s
coredns-5644d7b6d9-tdn9f                   1/1     Running   0          71s
etcd-k8smaster                             1/1     Running   0          13s
kube-apiserver-k8smaster                   1/1     Running   0          30s
kube-controller-manager-k8smaster          1/1     Running   0          19s
kube-proxy-kknp8                           1/1     Running   0          71s
kube-scheduler-k8smaster                   1/1     Running   0          32s

Join any number of worker nodes by running the following on each as root:
cd ../k8sworker1 
vagrant ssh
sudo -i 

Get the following information out of the kubeadm-init.out for joining the worker in the cluster.

kubeadm join k8smaster:6443 --token pzybeg.5ebv6ct0ts7q0dde \
    --discovery-token-ca-cert-hash 
sha256:b8bac2cb45f9e1e1c9db53dded9be20b3304462dc2586fe7ad5418e034013a58
  
cd ../k8slbvagrant sshsudo -idocker run -d --restart=unless-stopped --name nginx -p 
80:80 -p 443:443 -v /home/vagrant/nginx/nginx.conf:/etc/nginx/nginx.conf 
nginx:latest

Lens is the only IDE you’ll ever need to take control of your Kubernetes clusters. It is a standalone application for MacOS, Windows and Linux operating systems. It is open source and free. After you have installed Lens you can connect to your cluster using the Kubernetes config file, the only thing you have to do is change:

“server: https://k8smaster:6443” to “server: https://192.168.33.20:6443”

vagrant@k8smaster:~$ sudo cat /root/.kube/config

Start Lens and add the config file, don’t forget to change the server into https://192.168.33.20:6443.

Learning and starting with Kubernetes clusters on your local device with Lens is fun and a good starting point to experiment with Kubernetes.

Good luck and feel free to reach out if you have any questions or ideas.

Installing a Kubernetes cluster and connecting it to Lens

Splunk is vooral bekend van haar kracht om inzicht in applicaties te geven, maar wordt vaak ook vanuit security oogpunt gebruikt. Als Splunk consultant kom je daardoor vaak in aanraking met security gerelateerde use-cases. Doordat ik zelf weinig ervaring had met cybersecurity ben ik op zoek gegaan naar mogelijkheden om hier meer ervaring mee op te doen. In dit blog lees je een aantal voorbeelden waarmee ik zelf aan de slag ben gegaan. 

Een van de eerste oefeningen die ik tegenkwam was de website van Over the Wire.
Op de website staan verschillende “war games” waarmee je kunt oefenen met verschillende security concepten. Zo kan je beginnen met de Bandit wargame, deze is volledig gericht op beginners. Tijdens de verschillende levels leer je welke commando’s er in Linux zijn en moet je het wachtwoord voor het volgende level zien te achterhalen. Al snel ben je bezig met base64, openssl, nmap of zelfs een script om een pincode middels brute force te kraken.  

Als je alle Bandit levels hebt afgerond kan je nog 11 andere wargames op de site proberen waarbij het elke keer net een beetje moeilijker wordt. Met deze games leer je een hoop basis skills van security.

Na de oefeningen van Over the Wire, was ik op zoek naar een cursus waar ik theorie en praktijk samen kon brengen. Na verschillende opties die of heel veel geld kostten, of veel ervaring verwachtten, kwam ik uit bij TheCyberMentor.
Na verschillende YouTube videos van hem bekeken te hebben zag ik dat hij ook een Ethical Hacking cursus via Udemy aanbiedt. In de cursus komen veel verschillende onderwerpen aan bod zoals:

En er zit ook een onderdeel in om op de website Hack the Box 10 machines te kraken. De cursus is vooral gericht om informatie meteen toe te passen waardoor je het gelijk in de praktijk brengt. Dit is voor mij de meest prettige vorm van leren en zo blijf ik tijdens de cursus het meest gemotiveerd om door te gaan. Een aanrader!

Na de Ethical Hacking cursus wilde ik ook binnen Splunk verder kijken naar security.
Vanuit Splunk wordt er regelmatig een Boss of the SOC (BOTS) georganiseerd waarbij verschillende teams het tegen elkaar opnemen om binnen Splunk security vragen te beantwoorden door de data te analyseren. Door op deze manier leer je veel over de security mogelijkheden in Splunk.

Een aantal voorbeeldvragen zie je hieronder:

Het voordeel is dat je hier vrij eenvoudig ook zelf mee aan de slag kan gaan. Als je een Linux VM hebt dan kan je de dataset downloaden en de stappen die bij de scoring app staan volgen om je eigen BOTS machine in te richten. 

Hierna kan je op je eigen tempo de verschillende vragen proberen te beantwoorden. Enkele maanden terug hebben wij dit bij CINQ met de v2 dataset gedaan. In 2 teams gingen we aan de slag om te kijken wie de meeste punten kon halen, hierdoor leer je van elkaar. Dit is ontzettend leerzaam én gezellig om te doen met je Splunk team. We hopen dan ook dat we binnenkort een volgende Boss of the SOC sessie met de nieuwe dataset kunnen organiseren.

Naast BOTS is er nog een app die die je op weg kan helpen binnen Splunk en dat is Splunk Security Essentials. Deze app laat zien welke data security gerelateerd is, hoe je dit kan aansluiten en welke use-cases je vervolgens zou kunnen gebruiken. Het voordeel hiervan is dat de use-case wordt uitgelegd, er wordt aangegeven welke data je ervoor nodig hebt, en hoe de search binnen Splunk eruitziet.  Daarnaast zit er ook een MITRE ATT&CK framework in waarmee je kan zien welke use-cases door welke ATT&CK techniek gebruikt kunnen worden en of hiervoor de benodigde data al is aangesloten.

Het voordeel van de app is dat je op een simpele manier kan zien welke use-cases interessant zijn voor je eigen omgeving. Bij mijn opdrachtgever zijn we nu aan het kijken of we de koppeling naar Splunk Enterprise Security voor de MITRE ATT&CK informatie kunnen maken zodat we in Enterprise Security nog meer relevante informatie kunnen zien. 

Deze app heeft ook een demo omgeving die hier te vinden is.  Meer informatie over deze app is te vinden via splunksecurityessentials.com.

Aan de slag met security in Splunk

Bij Visser & Smit Hanab hebben we een review gedaan op de Terraform codebase. 

Bij deze review hebben we de de kwaliteit, complexiteit en technische validiteit van de code beoordeeld, en hoeverre deze gebruikt kon worden in een multi-cloud omgeving (Azure / AWS). 

Het eindproduct van deze opdracht was een rapport met aanbevelingen die de klant met onze hulp heeft geïmplementeerd.

Bij Visser & Smit Hanab hebben we een review gedaan op de Terraform codebase.

Terraform audit bij Visser & Smit Hanab

In de wonderlijke wereld van front-end technologie gaan de ontwikkelingen bijster snel. Het is niet altijd mogelijk om deze nieuwe ontwikkelingen direct toe te passen bij de opdrachtgever. Hier werk je namelijk vaak aan al een bestaande applicatie/project, waardoor je niet altijd direct in staat bent om nieuwe keuzes te maken. Toch krijg ik steeds vaker de vraag wat nu de beste keus is om een toekomstbestendige front-end neer te zetten. Dat vind ik persoonlijk een lastige vraag die ik niet binnen twee minuten kan beantwoorden, omdat dit ook te maken heeft met wensen, tijd, capaciteit en budget. In dit blog deel ik graag één van de keuzes die dit mogelijk zouden kunnen maken, namelijk Web Components. Zal dit de standaard worden en daarmee ook meer toekomstvast? 

In het kort gezegd zijn Web Components geïsoleerde componenten die je kan (her)gebruiken in HTML-pagina’s en webapplicaties. Een Web Component bouw je zonder tussenkomst van een toegevoegde bibliotheek. 

Als developer ben je in staat om je eigen Custom Element te schrijven, wat in principe dus je eigen HTML-element is met zijn eigen CSS en Javascript. Dit element is gebaseerd op web standaarden, waardoor het nu al in de meest gebruikte browsers toegepast kan worden. Ook Microsoft Edge ondersteund sinds januari 2020 dit principe. Dat maakt het bijzonder interessant.

Web components are based on existing web standards. Features to support web components are currently being added to the HTML and DOM specs, letting web developers easily extend HTML with new elements with encapsulated styling and custom behavior.

bron: https://www.webcomponents.org/introduction

Een Web Component bestaat uit vier specificaties, dit zijn:

Custom Elements
Een Custom Element is een HTML-element die je kan toevoegen aan de DOM.

Shadow DOM
Shadow DOM zorgt ervoor dat de styling gespecifieerd kan worden voor alleen dat element.

Es Modules
Het gebruik van ES Modules geeft de mogelijkheid tot het schrijven en gebruiken van modules op een standaard Javascript manier.

HTML Template
Declareer je eigen herbruikbare templates die getoond worden bij de rendering.

Hoe verhouden Web Components zich tot frameworks?

Nu wij simpel gezegd weten dat een Web Component een native component is, nu de vraag hoe deze zich verhoudt ten opzichte van de al bestaande frameworks. Ten eerste de vraag of wij moeten kiezen voor een Web Component, een framework of een combinatie van beiden? Uit mijn eigen ervaring heb ik nooit een combinatie van deze twee gezien. Neem ik het statement van React als voorbeeld, dan herken ik zeker dat elk framework zijn eigen problemen probeert op te lossen.

React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary. As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both. 

bron: https://reactjs.org/docs/web-components.html

Angular geeft zijn eigen invulling door het gebruik van Angular elements. Dat komt neer op een soort van afgeleide Web Component alleen dan met een isolatie van Angular eromheen.

De redenen waarom frameworks zo populair zijn komt omdat deze vaak bestaan uit één of meerdere van de volgende dingen: LifeCycle “de leef status” van het component voor view en data, data binding, routing, templating en herbruikbaarheid. Natuurlijk bevatten frameworks ook voordelen om sneller een applicatie te ontwikkelen, maar is het daarmee altijd de juiste keuze?

Ik denk het niet. Deze frameworks gebruiken namelijk ook gewoon native Javascript om de applicatie te laten runnen. Als voorbeeld neem ik het stukje routing. Zou ik dit zonder framework doen en in combinatie met Web Components, dan gok ik dat ik rond de 100-150 regels code nodig heb om de browser history API aan te sturen.

Natuurlijk is dit maar een minimale vergelijking en zijn er nog tientallen andere vergelijkingen te maken om een verschil aan te duiden. Dat zal alleen voor deze blog veel te veel (rand)informatie geven.

Het is niet zo simpel als dat het lijkt. Web Components zijn niet moeilijk om te ontwikkelen, maar met alle randzaken erbij kom je al snel op flink wat “maatwerk”. Wanneer ga je dan overstag? Ikzelf zie een aantal nuttige dingen.

Wanneer er in een organisatie de nodige applicaties ontwikkeld worden en/of er wordt met meerdere teams gewerkt, dan is het zeer belangrijk om niet in herhaling te vallen. Web Components werken onafhankelijk van andere frameworks. Doordat het zo dicht bij de standaard ligt, zou het dus een optie kunnen zijn om je design system (branding) hierin op te zetten. De componenten kunnen dan in elke willekeurige applicatie gebruikt worden. Een win-win situatie en daarmee dus ook toekomstbestendig? Wie weet.

Wanneer je met ontwikkelaars afspreekt om 1 taal te spreken en schrijven zal dat de kwaliteit van je code ook verhogen. Je kan naar mate de applicatie groeit, nog steeds vastbijten op web standaarden voor HTML, CSS en Javascript. Ik denk dat je ownership kan geven en eisen, maar nog belangrijker kan blijven houden. Daarnaast denk ik dat je als ontwikkelaar ook meer hebt aan het leren van web standaarden dan het leren van een framework.

Als je bereid bent om een investering te doen in Web Components, inclusief het hierboven beschreven “maatwerk”, dan denk ik dat je op termijn geld kunt besparen. Ontwikkelaars zullen namelijk sneller in staat zijn om de business te kunnen bedienen, doordat zij enkel bezig zijn met nieuwe componenten gebaseerd op web standaarden.

De nadelen van het gebruik van Web Components

Hoewel de meest gangbare browsers inmiddels Web Components ondersteunen blijft het toch een redelijk nieuw begrip. Daarom zal je ook rekening moeten houden met de volgende zaken.

Er zijn developers die erbij zweren dat alles per definitie in 1 file zou moeten staan, dus ook de styling van je component. Mijn voorkeur gaat echter om de styling altijd te scheiden van hetzelfde document, maar de styling moet wel alleen voor dat component toepasbaar zijn. Dit is meer een persoonlijke voorkeur, dan een hard argument.

Om een webapplicatie geschikt te maken voor een goede indexbaarheid voor zoekmachines als Google, dan vereist dat wel de benodigde best practices. Voor Google geldt dat de HTML gerenderd moet worden, zodat de bot de informatie kan lezen en begrijpen. 

Wanneer je Web Components gaat gebruiken, dan ben je in meer of mindere mate nog niet af van libraries. Er zijn namelijk een aantal libraries die het leven met Web Components een stuk fijner kan maken, bijvoorbeeld: Hybrids, lit-html, Skate.js, Slim.js of Stencil. Daarnaast is ook Open Web Components een actieve bibliotheek. Kort gezegd ben je dus niet af van het gebruik van third party stuff.

Dat de juiste frontend technologie kiezen een lastig vraagstuk is blijkt maar. Ik heb geprobeerd een kleine inkijk te geven op het gebied van Web Components. Terugkomend op de vraag of deze de standaard worden en toekomstbestendig zijn? Ik denk wel dat Web Components zeker de toekomst hebben. Juist omdat deze op de web standaard gebaseerd zijn. Alleen wanneer is een webapplicatie nu toekomstbestendig? In de afgelopen 30 jaar is er nog geen toekomstvaste applicatie neergezet die eeuwig blijft leven. 

De keuze om voor Web Components te kiezen zou het leven van de applicatie wel kunnen verlengen. Je blijft, voor nu, afhankelijk van libraries die het ontwikkelen makkelijker maken. Daarnaast is het ook nog maar de vraag of Web Components past bij de wensen, tijd, capaciteit en budget van de opdrachtgever. Er zijn nog niet heel veel bedrijven die nu al (volledig) gebruik maken van Web Components. In Nederland is ING er bijvoorbeeld heel actief mee bezig. Kijk je naar de trends van installatie, dan zie je dat lit-html wel aan het groeien is de afgelopen 6 maanden.

Om af te sluiten zie ik dus potentie in het ontwikkelen van Web Components. De vraag ernaar zal gaan toenemen. Ik zal het in elk geval altijd meenemen in mijn afweging tussen een framework als bijvoorbeeld Angular, Vue of Svelte en Web Components. Ik verklaar alleen niet mijn volledige liefde eraan. Op het gebied van front-end development blijven de ontwikkelingen immers nog steeds razendsnel gaan.

In de wonderlijke wereld van front-end technologie gaan de ontwikkelingen bijster snel. Het is niet altijd mogelijk om deze nieuwe ontwikkelingen direct toe te passen bij de opdrachtgever.

Web Components - de toekomst van front-end ontwikkeling?

Sinds 13 november 2019 is GitHub Actions officieel beschikbaar, de nieuwe CI/CD tool van Github. Nu bijna een half jaar verder, ben ik benieuwd hoe dicht Github Actions naar Azure Pipelines is gegroeid qua functionaliteiten maar ook in hoeverre Github Actions al Azure Pipelines kan vervangen. In dit blog zet ik de belangrijkste verschillen op een rij. 

Zowel een Github Action workflow als een Azure Pipeline is een configureerbaar geautomatiseerd proces dat bestaat uit één of meerdere "Jobs". Met dit proces bepaal je de CI/CD flow. 

In beide gevallen word de YAML syntax gebruikt.  Dit word vaak gebruikt voor "Configuration as Code". In dit bestand bepaal je de configuratie van de workflow/pipeline. De locaties van deze bestanden verschilt per oplossing. Bij Azure Pipelines zet je het YAML bestand azure-pipelines.yml in de root folder van het project. Bij GitHub Actions komt deze in de folder /.github/worksflows/<workflownaam>.yml. De YAML bestanden in deze folder worden automatisch opgepakt. Je kan zowel de .yaml of .yml als bestandsextensie gebruiken.

Wil je meer informatie over YAML zie: Learn YAML in five minutes.

Github Actions en Azure pipelines gebruiken voor vergelijkbare stappen soms verschillende benamingen, hieronder een opsomming van de verschillen. Github Actions wordt steeds als eerst genoemd en Azure Pipelines als tweede. 

Een event / trigger is een activiteit welke de Workflow / Pipeline triggert.  

Workflows kunnen net als Pipelines getriggerd worden door het pushen van commits of tags naar specifieke branches in de gekoppelde repository. Maar ook door Pull requests of een scheduled trigger. Naast deze standaard triggers bied Workflows nog een groot aantal activiteiten binnen Github welke de workflow kunnen triggeren. 

Kijk voor een lijst van alle Workflow en Pipeline triggers op Workflow Triggers en Pipeline Triggers.

Azure Pipeline ``stages`` zijn bedoelt om de activiteiten van de pipeline in fases te verdelen. Met gebruik van ``stages`` krijg je de mogelijkheid om de pipeline te pauzeren voor een handmatige check. Bijvoorbeeld wanneer een manager de release van de staging moet goedkeuren voordat deze door mag naar productie.

Github Actions heeft deze mogelijkheid niet. 

Zowel Workflows als Pipelines bestaan uit ``jobs``. Een ``job`` bestaat uit één of meerdere ``steps``. 

Een ``step`` kan bestaan uit een inline-script of een pre-packaged script. binnen Azure Pipelines ook wel een `task` genoemd. Een pre-packaged script is een `action` in Github Actions.

Een ``action`` of een ``task`` is een vooraf gemaakt script die je aan kan roepen in meerdere Pipelines of Workflows. Zowel Github Actions als Azure Pipelines bied built-in en custom ``actions``/``tasks``.

Het idee achter een custom ``action``/``task`` is het beheer van terug kerende activiteiten te versimpelen. Als je bijv. 10 Workflows of Pipelines hebt met een inline-script waar een aanpassing in nodig is. Zul je al die 10 Workflows/Pipelines moeten wijzigen. Met een ``action``/``task`` hoef je alleen de ``action`` of de ``task`` te wijzigen. De aanpassing is gelijk beschikbaar de eerst volgende keer dat de Pipelines draaien. Hierdoor hoef je niet meer al je Pipelines te wijzigen. 

Pipeline ``Tasks`` zijn beschikbaar in de Visual Studio Marketplace. Maar er is ook de mogelijkheid om ze zelf te schrijven.

Community ``Actions`` zijn beschikbaar via de Github Marketplace. Ook ``Actions`` kan je zelf schrijven.

In Github Actions worden ``jobs`` toegewezen aan een ``virtual environment``. Dit kan zowel een Github-hosted of een Self-hosted runner zijn. Je hebt de keuze uit een Windows, Linux of een MacOS enviroment.

Github self-hosted runners zijn nog niet zo heel lang beschikbaar. De belangrijkste verschillen tussen hosted en Github-hosted runners zijn:

Github-Hosted runners bieden een simpelere en makkelijkere manier voor het draaien van workflows. Terwijl self-hosted runners meer configuratie mogelijkheden bieden voor specifieke benodigdheden binnen een workflow.

In Azure Pipelines worden ``jobs`` toegewezen aan ``agent pools``. Een `agent pool` is een groep van gelijke ``agents``. Een ``agent`` kan zowel hosted zijn of self-hosted. Hier heb je dezelfde opties als in Github, Windows, Linux of MacOS. 

Als voorbeeld heb ik een simpele Angular app build pipeline gemaakt voor zowel Github Actions als Azure Pipelines binnen dezelfde repository zodat deze tegelijkertijd triggeren. [^1]  Omdat Github Actions nog geen stages ondersteunt heb ik hier geen gebruik van gemaakt. Hierdoor zijn de YAML bestanden makkelijk te vergelijken.  

name: Build & Publish Angular in Github Action Workflow
on:
  push:
    branches:
      - master
jobs:
  Build_Angular_App:
    runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2   
    - uses: actions/setup-node@v1
      with:
        node-version: 12.16.2
      name: Install Node.js
    - run: |
        npm install
        npm install -g @angular/cli
        npm run lint
        npm run build --prod
      name: npm install and build
    - uses: actions/upload-artifact@v1
      with:
        name: Artifact-GithubActionWorkflow
        path: dist/WorkflowvsPipeline
      name: Publish Artifact

 Het resultaat van de bovenstaande Github Actions Workflow: 

name: Build & Publish Angular in Azure DevOps Pipeline
trigger:
  - master
jobs:
  - job: Build_Angular_App
    pool:
      vmImage: 'ubuntu-latest'
    steps:  
      - task: NodeTool@0
        inputs:
          versionSpec: '12.16.2'
        displayName: 'Install Node.js'
      - script: |
          npm install
          npm install -g @angular/cli
          npm run lint
          ng build --prod
        displayName: 'npm install and build'
      - task: PublishPipelineArtifact@0
        inputs:
          artifactName: 'Artifact-AzurePipeline'
          targetPath: 'dist/WorkflowvsPipeline'
        displayName: 'Publish Artifact'

Het resultaat van de bovenstaande Azure Pipeline: 

 Azure Pipelines ondersteunt voor nu nog de classic editor, hoe lang deze nog beschikbaar blijft is onbekend. De classic editor bied de mogelijkheid om je CI configuratie in een GUI te definiëren in plaats van een YAML bestand. Github Actions heeft geen GUI editor en ondersteunt alleen YAML.

Azure Pipelines heeft een marketplace met veel kant en klare Pipelines en extensies. Ook Github Actions heeft een marketplace, maar is nog niet zo uitgebreid als die van Azure Pipelines. Dit zegt nu nog weinig omdat Github Actions nog redelijk nieuw is. Dit zal de aankomende tijd gaan veranderen doordat de github actions community verder zal groeien.

Azure Pipelines is minder strikt in de YAML structuur. Je kan bijv. taak definities weglaten wanneer je Pipeline maar uit één taak bestaat. Je hoeft dan niet de taak te definiëren, alleen de stappen zijn dan genoeg. Github Actions bied deze mogelijkheid niet.

Azure Pipelines ondersteunt ``stages ``, dit is zowel in de Classic editor als YAML beschikbaar. Stages bied de mogelijkheid om deployment workflows in verschillende fases op te delen. Bijv.  Build -> Test -> Staging -> Prod. 

Github Actions bied deze mogelijkheid niet.	

Kan ik Azure Pipelines vervangen door Github Actions?

Om eerlijk te zijn is het antwoord afhankelijk van de functionele eisen. Hoe complex je Workflow/Pipeline moet worden en of je afhankelijk bent van handmatige goedkeuringen van bijv. een manager. Dit verschilt natuurlijk per project.

Als je nog geen Azure Pipelines gebruikt maar wel al Github gebruikt als code repository, en je hebt geen manual approvals nodig, dan is Github Actions de juiste keuze om mee te beginnen.

Mocht je wel al gebruik maken van Azure Pipelines i.c.m. Github Repositories dan zou je bijv. je code kwaliteit checks naar Github Actions kunnen verplaatsen die dan weer je Azure Pipeline triggert wanneer de code voldoet aan alle voorwaarden.

Github Actions is de afgelopen maanden hard gegroeid, en is naast Azure Pipelines een mooie toevoeging aan de bestaande CI/CD tooling. Hou er rekening mee dat er nog vol aan Github Actions ontwikkeld wordt, dit kan betekenen dat de huidige "tekortkomingen" er over een paar maanden niet meer zijn.

Heb je vragen of opmerkingen? Laat het gerust weten!

[^1]: https://github.com/Luukxt8/workflowvspipeline

GitHub Actions vs Azure Pipelines

Vakmensen, dat zijn we. En wat we doen op het gebied van informatie- en communicatietechnologie helpt organisaties slim verder. Effectief en meetbaar bovendien. Aangenaam, CINQ. Specialisten in Data, DevOps en Development. Wij geloven in specialisten, vandaar de driedeling Data, DevOps en Development binnen ons bedrijf. Zo zorgen we dat jij excelleert, want je werkt het best waar je je het meest thuis voelt. Logisch, toch?

cinq_logo.png

CINQ ICT

We delen graag onze kennis over Data, DevOps en Development met je. Op ons blog lees je tips en tricks over bijvoorbeeld Splunk, Docker, Kubernetes en Java.

Onze laatste blogs