Voor Pondres in Tilburg - een bedrijf dat gespecialiseerd is in communicatie en fulfilment - hebben wij een review gedaan op de architectuur van een nieuw te bouwen containerplatform met Docker. 

Voor Pondres in Tilburg hebben wij een review gedaan op de architectuur van een nieuw te bouwen containerplatform met Docker.

Docker architectuur review bij Pondres

Recently I was asked to give a demo about PKI using HashiCorp Vault. Everyone with some history in Ops knows the painful manual work for renewing TLS certificates, putting it on the server and maybe even restarting your application or web server. This is the main reason why such certificates are often valid for one or even two years. So to show the power of having an API to manage your PKI and request certificates, I created a demo where you can completely automate the renewal of TLS certificates for your app on Kubernetes, using both Vault and Cert-Manager.

We will use Minikube to create a Kubernetes cluster where we can run Vault, Cert-Manager, Minikube's ingress controller and a webapp, where:

Vault will give us an API to request certificates for our own PKI.

Cert-Manager will manage the renewal of our certificate.

The ingress will expose our webapp on HTTPS.

We will first setup the prerequisites for demoing this certificate renewal automation:

Once the prerequisites are met, we are ready for the demo part which consist of:

Setup Cert-Manager and request certificate

Virtual Box. Ingress works pretty nice for Minikube with a vm driver. I use virtual box as a vm driver, but you can also choose other Minikube vm drivers.

I won't go into all the details of these prerequisites, but discuss only what we need.

Create Minikube cluster with ingress addon

minikube start --driver=virtualbox

minikube addons enable ingress


To install Vault we use Helm and just follow the docs from HashiCorp.

helm repo add hashicorp https://helm.releases.hashicorp.com
helm repo update
helm install vault hashicorp/vault \
    --set "injector.enabled=false"

# Get vault pod
kubectl get po vault-0

Wait for the vault-0 pod to get healthy and then unseal Vault. We write the Vault key to a file, so we can retrieve it when necessary. (This is clearly very insecure, but ok for this blog.)

# Create Vault unseal key
kubectl exec vault-0 -- vault operator init -key-shares=1 -key-threshold=1 -format=json > /tmp/demo-keys.json
cat /tmp/demo-keys.json | jq -r ".unseal_keys_b64[]"

# Unseal Vault
VAULT_UNSEAL_KEY=$(cat /tmp/demo-keys.json | jq -r ".unseal_keys_b64[]")
kubectl exec vault-0 -- vault operator unseal $VAULT_UNSEAL_KEY

We will often want to execute Vault CLI commands and can use the vault-0 pod to execute those. For instance like this:

# Get Vault token from our file
VAULT_TOKEN=$(cat /tmp/demo-keys.json | jq -r ".root_token")

# Get a shell in vault-0 pod with VAULT_TOKEN as environment variable
kubectl exec vault-0 -ti -- /bin/sh -c "VAULT_TOKEN=$VAULT_TOKEN sh" 

# Vault CLI example
vault token lookup

# Exit pod
exit

We enable Kubernetes Auth Method and connect our Kubernetes cluster with Vault. For now it is enough to know that

We will grant the Kubernetes service account issuer access to Vault

In this pki policy, the endpoints of our PKI engine are defined.

Note that these issuer service account and pki policy do not exist yet, that is fine, we will create them later.

# Prepare Vault CLI in `vault-0` pod
VAULT_TOKEN=$(cat /tmp/demo-keys.json | jq -r ".root_token")
kubectl exec vault-0 -ti -- /bin/sh -c "VAULT_TOKEN=$VAULT_TOKEN sh"

# Enable Kubernetes Auth Method
vault auth enable kubernetes
vault write auth/kubernetes/config \
    token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
    kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# Policy pki: read access to pki paths
vault policy write pki - <<EOF
path "pki*"                        { capabilities = ["read", "list"] }
path "pki/roles/example-dot-com"   { capabilities = ["create", "update"] }
path "pki/sign/example-dot-com"    { capabilities = ["create", "update"] }
path "pki/issue/example-dot-com"   { capabilities = ["create"] }
EOF

# Create Kubernetes Auth Method role: Grant service account `issuer` access via the `pki` policy
vault write auth/kubernetes/role/issuer \
    bound_service_account_names=issuer \
    bound_service_account_namespaces=default \
    policies=pki

# Exit pod
exit 

We will deploy a webapp and expose it with ingress, so it can use our TLS certificate to receive traffic over HTTPS.

For our ingress we use the domain name demo.example.com and a Kubernetes secret demo-example-com-tls where we will store our certificate.

Note: This Kubernetes secret demo-example-com-tls doesn't exist yet, but that is fine, we will create it later.

# Deploy webapp
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
# Create service
kubectl expose deployment web --port=8080
kubectl get service web

# Create ingress
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - demo.example.com
    secretName: demo-example-com-tls
  rules:
  - host: demo.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 8080
EOF

This ingress will get an external IP address (this can take some time) and since we use Minikube with a vm driver, this external IP address is equal to the IP of the vm.

# Show ingress external IP and Minikube's IP
kubectl get ingress
minikube ip

To make the demo more pretty, we will add this ip to our /etc/hosts file so we can browse to our domain.
Edit your hosts file with sudo vi /etc/hosts, like this:

# PKI Demo 
192.168.99.128 demo.example.com

You can then browse to https://demo.example.com, or use curl to go to our webapp.

The ingress controller will serve a default self-signed certificate since we did not configured any certificate yet.

# Ignore invalid cert
curl --insecure https://demo.example.com
# Show tls handshake details
curl -kivL https://demo.example.com

We have Vault running and connected to our Kubernetes cluster and we have a webapp exposed via ingress.

We are now ready to automate certificate renewal by:

We will enable PKI in Vault. For most settings the default values suffices for this demo, we only:

Give the root CA certificate a name which we can recognize: Demo Root Certificate Authority

With this Vault pki role we define what kind of certificates we are allowed to request, in this case: certificates for example.com and all it's subdomains and, most importantly, with a maximum time to live of 3 minutes: max_ttl=3m.

# Prepare Vault CLI in `vault-0` pod
VAULT_TOKEN=$(cat /tmp/demo-keys.json | jq -r ".root_token")
kubectl exec vault-0 -ti -- /bin/sh -c "VAULT_TOKEN=$VAULT_TOKEN sh"

# Enable PKI secret engine
vault secrets enable pki

# Generate root CA (and write to file)
vault write -format=json pki/root/generate/internal \
    common_name="Demo Root Certificate Authority" > /tmp/demo-root-ca.json
cat /tmp/demo-root-ca.json

# Configure pki api endpoints
vault write pki/config/urls \
    issuing_certificates="http://vault.default:8200/v1/pki/ca" \
    crl_distribution_points="http://vault.default:8200/v1/pki/crl"

# Create `pki` role to create certificates for example.com and all subdomains and with a maximum time to live of 3 minutes.
vault write pki/roles/example-dot-com \
    allowed_domains=example.com \
    allow_subdomains=true \
    max_ttl=3m

# Exit pod
exit

Now that we have an api to request certificates, we can start using it.

We will deploy Cert-Manager and configure Vault to be the issuer of the certificates. When that is done, we can define our certificate and Cert-Manager will request and renew the certificate when it will expire.

We install Cert-Manager v1.3.0 with Helm and just follow the docs from Jetstack. This will install Cert-Manager in a separate namespace and also install it's custom resource definitions CRD's.

kubectl create namespace cert-manager
helm repo add jetstack https://charts.jetstack.io
helm repo update

# Install Cert-Manager 
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v1.3.0 \
  --set installCRDs=true

# View pods
kubectl get pods --namespace cert-manager

# View CRD's
kubectl get customresourcedefinitions.apiextensions.k8s.io

From the CRD's we will use Issuer and Certificate.

First with CRD Issuer, we can define the issuer of the certificates. Recall the Kubernetes Auth Method configuration, where we granted the Kubernetes service account issuer access to our pki api endpoints. Hence we create a service account issuer in Kubernetes. We then define the Issuer CRD with a.o.:

Connect it to the Vault server http://vault.default (to the pki/sign/example-dot-com uri in particular)

Authenticate via the token of our issuer service account

# Create service account
kubectl create serviceaccount issuer

# Token of service account `issuer`
ISSUER_SECRET_REF=$(kubectl get serviceaccount issuer -o json | jq -r ".secrets[].name")

# Define issuer
cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: vault-issuer
  namespace: default
spec:
  vault:
    server: http://vault.default
    path: pki/sign/example-dot-com
    auth:
      kubernetes:
        mountPath: /v1/auth/kubernetes
        role: issuer
        secretRef:
          name: $ISSUER_SECRET_REF
          key: token
EOF

# Show issuer
kubectl get issuer

Second, with CRD Certificate, we can define our TLS certificate, with:

Name of the Kubernetes secret, where the certificate needs to be stored: demo-example-com-tls

Specify at which issuer the certificate needs to be requested: vault-issuer

Define properties of our certificate:
undefined

# Define certificate
cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: demo-example-com
  namespace: default
spec:
  secretName: demo-example-com-tls
  issuerRef:
    name: vault-issuer
  commonName: demo.example.com
  dnsNames:
  - demo.example.com
EOF

# View certificate CRD
kubectl get certificate

Cert-Manager can now request this certificate at our issuer. Once that is done, you will see that a new secret is created.

# See the request in the events
kubectl describe certificate demo-example-com

# New secret
kubectl get secrets demo-example-com-tls

We are done! Let's check if we can see our new TLS certificate.

Cert-Manager using this pki api to request a certificate

the certificate is stored as a Kubernetes secret demo-example-com-tls

Ingress gets demo-example-com-tls and uses it to enable TLS on our webapp

When we now browse to https://demo.example.com, or use curl to go to our webapp, we still get an invalid certificate. But when we look closer to the certificate, we see that it is a certificate from Vault.

In this blog our engineer Eric shows you how to automate the renewal of TLS certificates with Vault and Cert-Manager, running on a Kubernetes cluster.

How to automate the renewal of TLS certificates with Vault and Cert-Manager on Kubernetes

Automate the renewal of TLS certificates with Vault and Cert-Manager

In 2021 Java celebrates its 25th anniversary. As part of this anniversary Oracle offered to register for the Java SE 11 Developer exam for only 25 dollars (22 euros). This is an interesting offer, because normally this will set you back ten times as much. So I decided to go for it and to give it a shot. This offer was valid for two months, so there was a deadline to keep me focussed on my goal. In this blog I will give you some tips to pass this exam.

Before I get to this a little bit more background on myself. I did the Java 8 OCA exam in 2017 (so four years ago). Please note that this was the OCA version. The OCA version is a lot simpler than the OCP version. It will test you on far less topics. The Java SE 11 Developer is comparable to the former OCP versions.

Because of my previous experience I already knew about the kind of questions you can expect. The questions are, to put it mildly, misleading. The exam tries to trip you up with really obscure notations and almost correct options. To give an example, does the following line compile?

public static void main (String []args) {}

All Java developers recognise this as the main entrypoint of a Java program. Most developers will frown their brows on the part between the parentheses. Normally we see one of the following:

I had never seen String []args before, but apparently it is allowed, so it does compile. Most questions contain several of these “interesting” cases.

So to pass this (or any other Java exams) you have to become a human compiler. You need to know if code will compile or not. Half of the questions have an option that says the code will not compile. 

The first question is: Where should I start? 

Tip 1 - OCP Java SE 11 Developer Complete Study Guide

I used and recommend the Oracle Certified Professional Java SE 11 Developer Complete Study Guide from Jeanne Boyarsky and Scott Selikoff. This book has around 1300 (!) pages, but it has all the information that you need. It has the depth that you need to become the aforementioned human compiler. Furthermore it is also brimming with questions to test your knowledge and sharpen your skills. 

This book also comes with an online test environment in which you can customize the kind of exam you like to do. For instance you can specify that you only want questions about exceptions or security. You can also create an exam with only x questions or one that only contains questions that you incorrectly answered in the past. A great tool to prepare effectively. 

Tip 2 - Do not underestimate the difficulty of this exam.

The exam was much more difficult than I expected when I started this adventure. It took far more time and effort than I had planned to commit to this. In the intro of this blog I mentioned passing for the OCA 8 exam. I had to study quite a lot for this exam, but leading up to the exam I was pretty confident that I would pass. For this exam I studied thrice as hard and I could not predict the outcome. So in the end I put in about 120 hours to fail at my first attempt. 😞

Tip 3 - Practice a lot (and then even more)

After spending sixty hours on studying I took my first mock exam and I failed gloriously. I only answered 40 percent of the questions correctly. The exam asks really in depth stuff, so for me just studying was not enough. I had to practice and practice to familiarize myself with all the nooks and crannies of the Java language. So I spend another sixty hours doing as many practice questions and mock exams as humanly possible. I had to do the exam twice and I barely passed it the second time. 

Tip 4 - Look at the answers before reading the rest of question

All previous tips are about preparing for the exam. The last tip will be about the exam itself. It consists of 50 questions and you have to answer them in 90 minutes. That is 108 seconds per question. That is a scary little amount of time when you have to parse 15 lines of code. Normally you start with checking if the code compiles. So you start looking for compile errors. Once you have done that you try to understand what the code does. The code will not be straight forward. There will be strange constructs in there. There will be things that do not make sense in the real world. Finally you have to find the correct answer. This is a pretty tall order to complete in 108 seconds. Actually I was not able to do it consistently. So I had to change my approach. 

I started looking at the answers before I read the question and this really sped me up. Maybe there is no answer option that says that it does not compile. So you do not have to check for compile errors. Maybe there is an answer option that says it will give a compile error at a given line. Now you can check this line for obvious errors. These are only two examples, but you can get a lot of information from the possible answers. So use this information to your advantage to get the correct answer faster. 

Thank you for reading this blog and good luck passing the exam!

The Java SE 11 Developer exam is a tough cookie. Read our 4 essential tips to help you pass the exam.

4 Tips to pass the Java SE 11 Developer exam

We schrijven allemaal wel eens code die op een later moment een punt van frustratie wordt voor onszelf, of onze collega’s. Soms copy-paste je een stuk code (dupliceren) en komt het er niet van om dit op te schonen. Of je maakt een ontwerp beslissing die in eerste instantie goed lijkt, maar waarvan later blijkt dat het een tijdrovende fout is geweest. 

In deze blog zal ik twee grote frustratiepunten beschrijven, met de focus op Java, wanneer je code probeert te veranderen: dupliceren (copy-pasten) en het onnodig koppelen (coupling) ten gevolge van overerving (inheritance). 

Het kan erg frustrerend zijn wanneer je denkt klaar te zijn met het aanbrengen van een verandering, om er dan achter te komen dat je dezelfde verandering op een tiental andere plekken in je code moet herhalen, voordat het goed zal werken. 

Tijdens het ontwerpen van een systeem, zou je altijd het DRY principe moeten volgen: Elk stukje kennis moet een enkele, eenduidige, belangrijke vertegenwoordiging hebben binnen een systeem. Echter, betekent dit niet dat elke identieke regel tekst of code een duplicaat is. Het kan ook gewoon zo zijn dat de implementatie identiek is. 

DRY gaat over het dupliceren van kennis, die onder andere voorkomt in:

Vaak vergeet men dat documentatie ook geüpdatet moet worden, samen met de veranderingen die je maakt aan je codebase. Het enige wat erger is dan geen documentatie, is verkeerde of verouderde documentatie. Verouderde documentatie kan misleidend zijn en kan je een hoop extra werk kosten. 

Commentaar, of ‘comments’, is slechts een andere vorm van duplicatie. Functies en variabelen met duidelijke namen hebben geen comments nodig. Comments binnen methodes zijn een teken dat de methode te lang is. Deze zouden opgedeeld moeten worden in aparte methodes, met duidelijk beschrijvende namen.

Developers die niet weten wat hun teamgenoten aan het bouwen zijn, lopen het risico om vergelijkbare code te schrijven. Hierdoor dupliceren ze onbewust functionaliteit die al bestaat. Dit kan alleen worden verminderd door betere communicatie. Actieve en frequente communicatie tijdens de dagelijkse stand-ups, forums, etc. Het is dan ook verstandig om de source code en documentatie van anderen te lezen tijdens code reviews of informeel. 

En dan nu: duplicatie in code. Het is het beste om klein te beginnen met het verwijderen hiervan. Allereerst lokaliseer en verwijder je kleinere stukjes gedupliceerde code in aparte methodes. Hierdoor wordt het makkelijker om daarna de grotere stukken van gedupliceerde code te lokaliseren en verwijderen. Vergeet niet om test units te draaien na elke grote verandering, zodat je niet elke keer te veel werk moet terugdraaien. 

Verplaats gedupliceerde code van verschillende klassen, naar zijn eigen klasse.  Na het verwijderen, moet de nieuwe klasse gekoppeld worden aan de klasse die gebruikt wordt. In Java heb je twee opties:

• Optie 1:een 'has a'-relatie. De originele klassen kunnen een fractie van de nieuwe klasse krijgen als een private attribute. Dit wordt ook wel composition of delegation genoemd, omdat je functionaliteit delegeert aan componenten van een andere klasse.

• Optie 2: Een "is-a" -relatie. De originele klassen kunnen de nieuwe klasse uitbreiden.

Het belangrijkste om rekening mee te houden wanneer je een implementatieoptie kiest, is: Erfbelasting. Je moet nog een verandering maken en denkt dat je klaar bent. Maar helaas, je komt erachter dat je zojuist de code op een tiental andere plekken hebt gebroken, omdat meerdere klassen sterk met elkaar gekoppeld zijn.

Gelukkig zijn er een aantal goede methodes als het gaat om het verminderen van onnodige koppelingen. Eén daarvan is: Betaal geen erfbelasting. Inheritance/overerving is een vorm van koppeling en moet dus vermeden worden indien mogelijk. 

Waarschijnlijk is dit niet wat je geleerd hebt. Inheritance gebruiken voor gedragssamenstelling en polymorfisme is een gangbare praktijk die je in elk OOP-handboek aantreft. In de praktijk heeft het echter een aantal ernstige nadelen.

Allereerste: dit zul je je misschien niet realiseren, maar wanneer een klasse is overerft, ontstaat er koppeling tussen meerdere concrete classes. Een kind klasse is gekoppeld aan een ouder klasse, een "grootouder klasse" enzovoorts. Maar elk object dat dit kind klasse gebruikt, is ook gekoppeld aan al zijn voorouders. 

Ten tweede: in een beperkt domein is het logisch dat een auto een soort voertuig is. Maar zodra het domein waarin je werkt gecompliceerder en realistischer wordt, worden deze modellen complexer en bijna onmogelijk te vormen. Bijvoorbeeld: wat gebeurd er wanneer een auto ook een soort eigenvermogen, te verzekeren object, etc. is. In dit geval heeft de auto dus meerdere overervingen nodig. Dat is niet alleen onmogelijk in sommige talen, zoals Java, maar indien het wel mogelijk is, eindig je vaak met complexe modellen die je alleen maar hoofdpijn bezorgen. 

In plaats daarvan, kun je één van deze technieken gebruiken, zodat je nooit meer inheritance nodig hebt:

Interfaces: het implementeren van interfaces geeft je polymorfisme zonder inheritance. Deze objecten bevatten normaal gesproken geen implementatie en een klasse kan een oneindig aantal implementeren

Delegation: door het implementeren van ‘class instance’ als een attribute, kun je alle onnodige methodes van de klasse die je niet gebruikt verbergen. Hiermee verminder je grotendeels de complexiteit. Dit betekent echter wel dat je meer code zal moeten schrijven.

Mixins: het principe van een mixin is simpel. Je wil klassen en objecten kunnen uitbreiden met nieuwe functionaliteit, zonder inheritance te gebruiken. Stel dat je twee gerelateerde functies zou hebben, genaamd 'find(id)' en 'findAll()', en je wil dat meerdere klassen in staat zijn om deze functies te gebruiken. Je wil natuurlijk geen inheritance gebruiken, maar delegation voegt weer onnodige code toe. Als de taal waarin je programmeert over deze optie beschikt, zou het er ongeveer zo uitzien:

// in sudo code

mixin CommonFinders {
  def find(id){ … }
  def findAll(){ … }
}
class AccountRecord implements BasicRecord with   CommonFinders { … }

Dit is helaas niet beschikbaar in Java, maar sinds Java 8 kunnen we interfaces definiëren met (public) default methodes. Hierdoor kunnen we methodes toevoegen met implementaties aan interfaces. In Java 9 is de mogelijkheid toegevoegd om private methods in interfaces te gebruiken, wat het mogelijk maakt om schone default methods te hebben. In Java kunnen we een mixin die een interface gebruikt op de volgende manier nastreven:

// in Java 9+ code

public interface CommonFindersMixIn {
  default Record find(String id) { … }
    default Record findAll() { … }


// some private methods
// private void example () { … }
}

class AccountRecord implements   BasicRecord, CommonFindersMixin { .. }

Eén probleem blijft bestaan. Omdat private attributes nog steeds niet toegestaan zijn binnen interfaces, beperkt dit de opties die je hebt wanneer je complexe methodes schrijft. In dit geval zal je dus geen andere keuze hebben dan delegation te gebruiken en dus nog een beetje meer code te moeten schrijven. 

Duplicatie en inheritance zijn niets meer dan anti-patterns. Ze hebben voordelen op de korte termijn, maar bezorgen je uiteindelijk alleen maar problemen. Clean code is niet alleen beknopt en zonder duplicatie, maar het vergroot ook geen concrete classes tenzij dit absoluut noodzakelijk is. 

Referenties
David Thomas and Andrew Hunt (2020): The Pragmatic Programmer. 
Michael Feathers (2005): Working Effectively with Legacy Code.
Nicolo Pignatelli (2018): Inheritance Is Evil. Stop Using It. 

Dupliceer geen bestaande code en betaal geen erfbelasting

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_logo_square.png

CINQ ICT

En, hoe lijkt het? Ben jij de nieuwe front-end developer die onze klanten verder helpt? Solliciteer dan meteen via de sollicitatiebutton. Doe het wel voor [sluitingsdatum], want daarna sluiten we de vacature.

Wil je de details van deze vacature tot achter de komma? Neem dan contact op met Marc Jacobs via marc@cinqict.nl of 06 – 51 08 74 37.

Sinds 2013 zetten we onze consultants in op hoogwaardige IT-projecten door heel Nederland. Met de kennis die onze specialisten in huis hebben, adviseren we teams en zetten we koers naar innovatie. Nieuwe tooling helpt ons om klanten keer op keer te verrassen. Tussen alle IT-consultancybureaus vallen we misschien niet direct op in wat we doen. Maar wél in hoe we het doen. Daarmee hebben we naam en faam gemaakt in verschillende sectoren en daar gaan we het liefst nog even mee door.

CINQ is opgesplitst in 3 business units met elk een eigen expertise. Niet dat we ervan houden om in hokjes te denken, maar dit werkt in de praktijk nu eenmaal het beste. Ook voor onze klanten die een beroep doen op jou als front-end developer. Onze developers zitten in heel Nederland. We draaien onze hand niet om voor grote projecten met de nodige complexiteiten. Sterker nog, die doen we misschien wel het liefst. Toch zijn we ook te porren voor kleinere opdrachten, zolang we klanten ermee kunnen helpen. En dat doen we het liefst, terwijl jij nieuwe kennis opdoet en verder groeit als specialist in je vakgebied.

cinq-overall.mp4

Als front-end developer breng jij beeldbepalende organisaties in het Nederlandse bedrijvenlandschap naar een hoger niveau. Daar ben jij de aangewezen front-end developer voor, die zichzelf continu verder ontwikkelt. 

Ooit gedacht om te werken voor een IT-consultancybureau? Niet? CINQ again, zeggen we dan. Want of je nu veel afwisseling in projecten wilt, of juist langer aan een organisatie verbonden wilt zijn: beide opties zijn mogelijk. Je werkt als front-end developer voor aansprekende klanten die jouw kennis en inzichten nodig hebben. Ondertussen zijn er je CINQ-collega’s met wie je kennis deelt, functionaliteiten bestudeert en nieuwe technieken onderzoekt. Zo kun jij klanten verrassen en van de vrijheid als front-end developer genieten. Een baan uit duizenden, waar je bijvoorbeeld: 

grote of kleine projecten draait, afhankelijk van wat jij wilt.

spreekt op congressen, vakinhoudelijke blogs schrijft en workshops verzorgt.

werkt voor klanten als grote banken, de Politie of luchthaven Schiphol.

cinq-development.mp4

Bekijk de video en maak kennis met onze developers

Als front-end developer kan jij werken met de nieuwste technieken voor toffe klanten zoals grote banken, de Politie of luchthaven Schiphol. Haak je aan bij CINQ?

Front-end developer

Zo goed als we bij CINQ voor onze klanten zijn, zo goed willen we ook voor jou zijn. Daarom krijg je direct een vast contract voor 36 of 40 uur per week. Bij deze vacature horen de volgende arbeidsvoorwaarden: 

een brutomaandsalaris tussen € 4.000 en € 5.500, afhankelijk van je kennis en ervaring.

8% vakantiegeld en 24 vakantiedagen op basis van een fulltime dienstverband.

een telefoonvergoeding en een laptop naar keuze.

€ 1.000 budget om je thuiswerkplek goed in te richten

een auto van de zaak óf mobiliteitsbudget met een kilometervergoeding.

leuke uitjes, waaronder stedentrips en skiweekenden.

ieder jaar een toffe gadget als eindejaarsgeschenk. Bijvoorbeeld een Sonos One, Beats koptelefoon, Playstation 4 of Google Nest.

bezoek conferenties zoals CSS Day, Fronteers of VueJS Amsterdam

Als front-end developer kan jij werken met de nieuwste technieken voor toffe klanten zoals grote banken, de Politie of luchthaven Schiphol.

36 - 40 uur per week

Gedreven, analytisch en voldoende doorzettingsvermogen om succes te boeken. Jij bent als front-end developer niet voor 1 gat te vangen, want voor complexe uitdagingen vind je de beste oplossingen. In deze rol heb je veel contact met de klant en daarom is goed communiceren uiterst belangrijk. Daar mag humor niet in ontbreken. Als er nieuwe ontwikkelingen of tools voorbijkomen, ben jij er als eerste bij om ze te onderzoeken. Het liefst ga je er meteen mee aan de slag. Als front-end developer heb jij:

ongekende front-end coding skills. Die heb je je bijvoorbeeld eigen gemaakt in een rol als software engineer of ontwikkelaar.

ervaring met relevante front-end frameworks, zoals Angular of React.

bedreven in het schrijven van unit testen.

goed oog voor design en vaardig met implementaties van Design Systems, via bijvoorbeeld StencilJS.

ervaring met Agile softwareontwikkeling in een DevOps-omgeving.

En, hoe lijkt het? Ben jij de nieuwe software engineer die onze klanten verder helpt? Solliciteer dan meteen via de sollicitatiebutton. Doe het wel voor [sluitingsdatum], want daarna sluiten we de vacature.

CINQ is opgesplitst in 3 business units met elk een eigen expertise. Niet dat we ervan houden om in hokjes te denken, maar dit werkt in de praktijk nu eenmaal het beste. Ook voor onze klanten die een beroep doen op jou als back-end developer. Onze developers zitten in heel Nederland. We draaien onze hand niet om voor grote projecten met de nodige complexiteiten. Sterker nog, die doen we misschien wel het liefst. Toch zijn we ook te porren voor kleinere opdrachten, zolang we klanten ermee kunnen helpen. En dat doen we het liefst, terwijl jij nieuwe kennis opdoet en verder groeit.

Helemaal thuis in de wereld van back-end development? Als specialist breng jij beeldbepalende organisaties in het Nederlandse bedrijvenlandschap naar een hoger niveau. Daar ben jij de aangewezen software engineer voor die zichzelf continu verder ontwikkelt. 

Ooit gedacht om te werken voor een IT-consultancybureau? Niet? CINQ again, zeggen we dan. Want of je nu veel afwisseling in projecten wilt, of juist langer aan een organisatie verbonden wilt zijn: beide opties zijn mogelijk. Je werkt als software engineer voor aansprekende klanten die jouw kennis en inzichten nodig hebben. Ondertussen zijn er je CINQ-collega’s met wie je kennis deelt, functionaliteiten bestudeert en nieuwe technieken onderzoekt. Zo kun jij klanten verrassen en van de vrijheid als software engineer genieten. Een baan uit duizenden, waar je bijvoorbeeld: 

Bekijk de video en maak kennis met onze software engineers

Helemaal thuis in back-end development? Als specialist breng jij beeldbepalende organisaties in het Nederlandse bedrijvenlandschap naar een hoger niveau.

Back-end developer

bezoek conferenties zoals JavaOne, Devoxx en JFall.

Helemaal thuis in de wereld van Java of Kotlin? Als specialist breng jij beeldbepalende organisaties in het Nederlandse bedrijvenlandschap naar een hoger niveau.

Gedreven, analytisch en voldoende doorzettingsvermogen om succes te boeken. Jij bent als software engineer niet voor 1 gat te vangen, want voor complexe uitdagingen vind je de beste oplossingen. In deze rol heb je veel contact met de klant en daarom is goed communiceren uiterst belangrijk. Daar mag humor niet in ontbreken. Als er nieuwe ontwikkelingen of tools voorbijkomen, ben jij er als eerste bij om ze te onderzoeken. Het liefst ga je er meteen mee aan de slag. Als software engineer heb jij:

ongekende coding skills. Die heb je je bijvoorbeeld eigen gemaakt in een rol als software developer of Java ontwikkelaar.

ervaring met relevante back-end frameworks zoals Spring Boot

En, hoe lijkt het? Ben jij de nieuwe data engineer die onze klanten verder helpt? Solliciteer dan meteen via de sollicitatiebutton. Doe het wel voor [sluitingsdatum], want daarna sluiten we de vacature.

Wil je de details van deze vacature tot achter de komma? Neem dan contact op met Marc Jacobs via marc@cinqict.nl of 06-51087437.

CINQ is opgesplitst in 3 business units met ieder een eigen expertise. Niet dat we ervan houden om in hokjes te denken, maar dit werkt in de praktijk nu eenmaal het beste. Ook voor onze klanten die een beroep doen op data engineers. Bij een klant meedraaien in een Splunk-team tot aan het uit de grond stampen van een splinternieuwe dataomgeving: als dataspecialist komt er van alles op je bord. En je collega’s van CINQ tref je bij een gezamenlijke data-kantoordag, kennissessie of memorabel uitje. 

Door efficiënt datagebruik help jij onze klanten vooruit. Banken, overheidsinstanties, onderwijsinstellingen: in jouw volgende opdracht krijg je volop de ruimte voor eigen inbreng.

De charme van een IT-consultancybureau als CINQ is dat jij als data engineer over de vloer komt bij meerdere klanten. Soms voor een langdurig project, soms voor een kortere opdracht. Jij helpt ze data te benutten en krijgt de vrijheid om dat te doen op basis van je eigen inzichten. Jij ziet Splunk als de hamer in een gereedschapskist; een onmisbare tool om je werk mee uit te voeren. Meer waarde uit data halen is jouw doel, via proof of concepts verbetertrajecten en implementaties van Splunk-omgevingen. Hierin houd jij je bezig met het:

onderhouden en beheren van een Splunk-omgeving voor een optimale performance.

komen met verbetervoorstellen richting de klant.

cinq-data.mp4

Bekijk de video en maak kennis met onze Splunk engineers

Door efficiënt datagebruik help jij onze klanten vooruit. In jouw volgende opdracht krijg je volop de ruimte voor eigen inbreng.

Splunk Engineer

Zo goed als we bij CINQ voor onze klanten zijn, zo goed willen we ook voor jou zijn. Daarom krijg je een direct een vast contract voor 36 of 40 uur per week. Bij deze vacature horen de volgende arbeidsvoorwaarden:

een brutomaandsalaris tussen € 3.000 en € 5.000, afhankelijk van je kennis en ervaring.

8% vakantiegeld en 24 vakantiedagen op basis van een fulltime dienstverband

De ideale kandidaat bestaat misschien niet. Toch zoeken we iemand die er dichtbij in de buurt komt. Want als data engineer ben je je ervan bewust dat jouw rol altijd in ontwikkeling is. Daarom doe je graag nieuwe kennis op en ben je creatief in het bedenken van oplossingen om klanten te verbluffen. Je bent nieuwsgierig, hebt een sterke klantfocus en kan zelfstandig uit de voeten. Dit breng je mee: 

ervaring met het zelfstandig ontwerpen, bouwen en implementeren van een data-omgeving. Bijvoorbeeld vanuit een eerdere rol als data consultant, data analist, data architect of data scientist. 

ruime ervaring met Splunk, ELK stack of andere vergelijkbare producten.

kennis van Python of een andere scripttaal.

eventueel kennis van DevOps, CI/CD-tooling (Docker, Kubernetes, AWS/Azure, Rancher of Terraform) is beslist een meerwaarde.

En, hoe lijkt het? Ben jij de nieuwe DevOps engineer die onze klanten verder helpt? Solliciteer dan meteen via de sollicitatiebutton. Doe het wel voor [sluitingsdatum], want daarna sluiten we de vacature.

Sinds 2013 zetten we onze consultants in op hoogwaardige IT-projecten door heel Nederland. Met de kennis die onze specialisten in huis hebben, adviseren we teams en zetten we koers naar innovatie. Nieuwe tooling helpt ons om klanten keer op keer te verrassen. Tussen alle IT-consultancybureaus vallen we misschien niet direct op in wat we doen. Maar wél in hoe we het doen. Daarmee hebben we naam en faam gemaakt in verschillende sectoren en daar gaan we het liefst nog even mee door. 

CINQ is opgesplitst in 3 business units met ieder een eigen expertise. Niet dat we ervan houden om in hokjes te denken, maar dit werkt in de praktijk nu eenmaal het beste. Ook voor onze klanten die een beroep doen op jou als DevOps engineer. Banken, onderwijsinstellingen, overheidsorganisaties: de bedrijven waar wij voor werken zijn groot en divers. Voor jou betekent dat werken aan opdrachten waar je van alles tegenkomt en nieuwe dingen ontdekt. Hoewel je vooral bij klanten werkt, heb je met je CINQ-collega’s een actieve community voor game-avonden en k8s-prep-avonden. Bij CINQ ontwikkel je je in rap tempo en heb je toegang tot alle tooling die je nodig denkt te hebben.

Draai aansprekende projecten die de grootste organisaties in Nederland steviger op de kaart zetten op het vlak van DevOps. Techniek is continu aan het veranderen en daar weet jij alles over vertellen. 

Iedere organisatie heeft een andere DevOps-cultuur door uiteenlopende behoeftes en wensen. Jij sluit naadloos aan op wat klanten willen en komt met een passend antwoord in de vorm van tooling en technieken. Samen met je collega’s van CINQ loop je voorop met je kennis en vanuit die positie voeg jij de meeste waarde toe voor klanten. En omdat de markt steeds weer verandert, blijf je gefocust op de allerlaatste ontwikkelingen. Projecten waar onze DevOps engineers aan werken zijn onder andere:

bouwen van een Kubernetes cluster op Microsoft Azure.

implementeren van Hashicorp Vault op Azure en AWS.

migreren van applicaties van on-premise naar de cloud.

inrichten en verbeteren van CI/CD pipelines.

cinq-devops.mp4

Bekijk de video en maak kennis met onze DevOps engineers

Zo goed als we bij CINQ voor onze klanten zijn, zo goed willen we ook voor jou zijn. Daarom krijg je een direct een vast contract voor 36 of 40 uur per week. Al is parttime werken ook mogelijk. Bij deze vacature horen de volgende arbeidsvoorwaarden:

een brutomaandsalaris tussen € 3.500 en € 5.500, afhankelijk van je kennis en ervaring.

bezoeken van conferenties, zoals DockerCon en DevOps Days.

Draai aansprekende projecten die de grootste organisaties in Nederland steviger op de kaart zetten op het vlak van DevOps.

DevOps Engineer

DevOps zit in je bloed. Of je ademt DevOps, mag ook. In ieder geval voel jij je thuis in een DevOps-omgeving. Je hebt een sterke drive om de laatste technieken te leren kennen en toont inlevingsvermogen. Je begrijpt klanten, onderkent hun problemen en gaat vanuit jouw expertise op zoek naar een passend antwoord. Zowel inhoudelijk als communicatief weet jij iedere klant te overtuigen. Daar breng je het volgende voor mee:

ervaring met DevOps-tooling, cloudoplossingen en CI/CD.

Docker architectuur review bij Pondres

Meer blogs