De afhankelijkheid van Amerikaanse cloudproviders zoals Azure, AWS en Google Cloud groeit al jaren. Maar wat betekent dat voor onze digitale soevereiniteit in Europa — en voor organisaties in Nederland?

Onze engineers doken voor je in dit onderwerp. We onderzochten Europese alternatieven zoals OVH, Stackit en Cyso Cloud, testten hun mogelijkheden en bekeken hoe volwassen deze platforms inmiddels zijn. De conclusie: de Europese cloud is nog in ontwikkeling, maar groeit snel en biedt interessante kansen voor wie voorbereid wil zijn op de toekomst.

Tijdens onze Europese Cloud Meetup delen Noud en Bouke hun bevindingen: van praktische migratie-ervaringen tot een eerlijke vergelijking tussen Europese en Amerikaanse aanbieders.

Wil je weten hoe ver de Europese cloud écht is?

Kom op 17 november naar de Meetup bij CINQ en kom er zelf achter.
Meld je aan via deze link en verzeker jezelf van een plekje.

Natuurlijk zorgen we voor een hapje eten en een drankje en daarna nemen twee CINQ’ers je mee in de wereld van de Europese cloud. 

Noud Savenije onderzoekt in zijn talk “Kubernetes in Europe: Can European Cloud Providers Compete with the American Giants?” of spelers als OVH, Hetzner en Stackit klaar zijn om bedrijfskritische Kubernetes workloads te draaien.

Bouke Nijhuis neemt ons in  neemt ons in “Migrating my Azure Function to the European Cloud” mee in zijn praktijkervaring: hoe verloopt de overstap van Azure naar Stackit en Scaleway? Met live demo’s laat hij zien waar het soepel gaat en waar je tegenaan kunt lopen.

17:30 ontvangst
18:00 eten
18:30 start presentaties
19:30 napraten & borrel

CINQ ICT, Burgemeester Stramanweg 101, Amsterdam

Ga naar https://www.meetup.com/cinq-ict/events/311355919/ om je aan te melden.

Hoe volwassen is de Europese cloud? Tijdens de EU Cloud Meetup van CINQ ontdek je of OVH, Stackit en Scaleway kunnen concurreren met Azure, AWS en Google Cloud.

Europese Cloud Meetup: Ontdek Alternatieven voor Amerikaanse Cloudproviders | CINQ

17 november: Europese Cloud Meetup

Not too long ago, I started working on an assignment where I was responsible for setting up the security layer. I had done bits and pieces before - throw in some annotations, lock down a couple of endpoints - but this time it was different. 

JWTs, authentication flows, token validation, role-based access. The whole thing! I kind of knew what JWTs were - those long tokens you slap into a header - but I hadn’t really sat down and understood how it all worked. I knew just enough to be dangerous! Until now. 

And as someone who plays drums in a band, I started to notice something familiar about it. If there’s one thing I’ve learned from years of playing in a band, it’s this: you don’t get into the venue without the right pass. Doesn’t matter if you’re the lead guitarist or the guy carrying the snare drum -  no pass, no entry! The same principle can be applied when building web apps.

Your front-end is like the roadie showing up at the venue (a.k.a. your back-end). It wants access, it wants to get in and do its thing. But the back-end doesn’t allow everyone in. He has got to check some credentials.

And that is where JWT (pronounced as ‘jot’) comes into play.

Let’s say you’ve built a slick front-end app. It’s flashy, fast, and ready to rock. Now it needs to make some calls to your back-end - to fetch user data, update profiles, maybe even post some setlists. For the non-musicians among us, a setlist is a list of songs you, as a band, plan to play during a gig. Until someone in the audience yells a request and chaos wins.

Here’s the issue: how does the back-end know who’s knocking?

As a back-end,  you don’t want to ask for a username and password on every request that comes in - that would be like showing your passport and filling out a form every time you walk past a security guard on tour. Exhausting. What we need is a backstage pass - a one-time signed token that says: “Yeah, this guy is with the band.”.

JWT stands for JSON Web Token. It’s a compact, URL-safe string made up of three parts in the following format:

[header].[payload].[signature]

Header: says what kind of pass this is, and how it was signed.  

Payload: the actual info: who the token belongs to, what roles they have, and (very important!) when it expires.

Signature: the real magic. It’s the tourmanager/organizer's signature - proof that this pass is legit and wasn’t faked in the parking lot.

Please don’t worry too much for now about the unknown words/abbreviations in the following payload example. A typical payload might look something like this:

 {
   "iss": "Creative Artist Agency",
   "sub": "user123",
   "name": "Dave Grohl",
   "role": "drummer",
   "exp": 1735689600
 }

The payload is made up of so-called claims. Claims are key-value pairs. Nothing more, nothing less. They carry the info you want to communicate. By the way, the term claim isn’t JWT trying to be fancy. In real life, a claim is when someone says something is true. When you put these in a JWT you are embedding statements (claims) about an identity - and you are expecting the receiver to trust them … if the token is valid and properly signed, that is!

From a specification point of view (RFC 7519) none of the claims you put in the JWT are required. You could even send a JWT with an empty payload, but somehow that doesn’t sound very practical. Although they are not required, certain claims are recommended and often used in practice. For example, you will always find the exp (= expiration time) claim on a JWT when dealing with authentication and/or authorization. 

Again, not required but extremely recommended. Especially exp, to prevent forever-valid tokens.

Let’s walk through the typical tour (aka JWT dance between front-end and back-end).

If we were to draw a picture of the whole thing, it would look something like this.

There are 3 actors involved in this process:

an authentication server (e.g. Google or your own developed authentication server)

Your user logs in through the front-end. The credentials go to the authentication server. The authentication server checks them, and confirms they’re legit (or not).

If all checks out then the authentication server creates and signs a brand new JWT: a signed, encoded backstage pass containing the user's ID and role. It uses a key pair to do this: a private key, kept secret like the tour manager’s official stamp, and a public key, which anyone on the team can use to verify that stamp. The private key signs the pass so it can’t be forged, and the public key helps the backend know it’s the real deal - no need to call HQ. Once signed, the token gets sent to the front-end, ready to be flashed at the next venue.

The front-end stashes it - usually in memory or localStorage, ready to rock. This token will now go on tour with every API call to the back-end.

Whenever the front-end wants to access a protected route on the back-end (like /api/setlists), it adds the token in the Authorization header of the request and this looks like this:

Authorization: Bearer eyJraWQiOiIwODI2MDdmMi05NTBkLTRkNGEtOTk0Yy1kZWFkNDY3ZDQy...   

The back-end receives the request, checks the token’s signature, confirms it hasn’t expired, and makes sure the user has the right role. But how do we check the signature? That’s where the public key part of step 2 comes into play. In order to check the JWT, the back-end needs the public key part of the key pair with which the JWT has been signed. What you usually see is that the authentication server exposes a special endpoint for retrieving the much needed public key. Only with that public key in hand can the back-end determine if the JWT has been issued by your authentication server, isn’t fake and/or hasn’t been tampered with. So, if everything checks out, you’re in.

If the security check succeeds then there is nothing left to do, other than executing the business logic and returning a response to the front-end. For as long as the JWT is valid, the front-end has access to the back-end.

Traditionally, web apps used sessions to keep track of who’s logged in. When a user logs in, the server creates a session - like writing their name on a clipboard - and stores it in memory or a database. Each time the user makes a request, the server checks that clipboard to see if they’re on the list.

Now, why then all this hassle of introducing extra components - an authentication server, tokens, signatures, the whole backstage circus with JWTs? Because you want your gig to scale! Sessions require the back-end to remember things - who’s logged in, where they’ve been, what they had for lunch. JWTs don’t. They’re stateless, meaning every server on your tour can check a pass and say, “Yep, looks good,” without phoning home to some central bouncer.

Think of it like this: instead of relying on one grumpy security guy with a clipboard at HQ, every venue on the tour has a scanner that instantly verifies your pass. They don’t need to call anyone, check a spreadsheet, or argue about your laminate - the token speaks for itself.

JWTs are awesome, but not bulletproof. Here’s where they can trip you up:

They expire - and until then, they can’t be revoked. If someone steals one, they’re in until it dies.  With this in mind you should always keep the lifespan of a JWT as short as possible. As a general rule of thumb a JWT access token should be valid for just a few minutes (certainly not hours). By the way, saying that JWTs can’t be revoked isn’t 100% true, you can in fact revoke them, but only by adding a centralized check - like a token blacklist or by means of tracking token IDs in a database. But, by doing so this would remove their stateless (and therefore scaling) benefits.

They’re readable - don’t put sensitive info in them. They're base64 encoded, not encrypted.

Storage matters - don’t put them in a place where JavaScript can easily grab them if you have XSS vulnerabilities.

As mentioned above, JWTs expire. Then what? Well, then we have to start the dance all over again. Or not? Think of your JWT as a temporary backstage pass - it gets you in, but only for a set amount of time. When it expires, you preferably don’t want to make the user log in again. You want the user experience to be as smooth as possible. That’s where the refresh tokens come in!

The refresh token is like a second pass that lives quietly behind the scenes - longer-lived, not used on every request. When the short-lived access token expires, the front-end uses the refresh token to ask for a new one. Kind of like walking up to the tour manager/organizer and saying, “Hey, can I get a new pass? Mine just ran out.” Important to remember: just like your JWT, do not lose this pass or show it off to other groupies!

your JWTs stay short-lived which reduces risk.

your users stay logged in without even noticing.

your back-end still has control. In contrast to JWTs, refresh tokens can be revoked if needed. 

Think of the refresh token as a special, long-lived backstage pass - but one that the tour manager keeps track of on a list behind the scenes. If someone causes trouble, spills beer on the mixer, or just looks shady, the manager can strike that pass off the list. From that point on, even if they flash the same pass, they’re not getting a new one. 

Some tours go even further with token rotation: every time you use the refresh token, the manager gives you a brand new one and burns the old one. It’s like swapping wristbands at every venue, so even if one gets stolen, it won’t work the next night. Unlike JWTs, which just roam free until they expire, refresh tokens give your back-end the power to kick someone off the tour at any moment.

It’s your digital backstage pass. Signed by the authentication server, handed to the front-end, and flashed at every endpoint of the back-end that asks: “Are you supposed to be here?”.

As a drummer, I’ve been let into a lot of venues with nothing more than a worn-out laminate pass on a keycord. If it’s signed, it's trusted. The same goes for your front-end app!

Leer hoe JWTs werken aan de hand van een muzikale metafoor: ontdek hoe JSON Web Tokens je webapp beveiligen met digitale backstage passen, inclusief uitleg over authenticatie, token flows en refresh tokens.

“No pass, no entry” - a musician’s take on JWTs

Onlangs kwamen onze engineers bij elkaar om een onderwerp te bespreken dat steeds urgenter wordt: soevereine cloudinfrastructuur. We spraken over Europese cloudoplossingen, de digitale onafhankelijkheid van Nederland, en onze huidige afhankelijkheid van Amerikaanse cloudproviders. In deze blog delen we de belangrijkste inzichten uit dat gesprek – én de volgende stappen die we gaan zetten.

Ons gesprek begon met een opvallende constatering: in de media gaat het vrijwel altijd over de “grote drie” Amerikaanse cloudproviders – Microsoft Azure, Amazon Web Services en Google Cloud. Zij domineren de markt, maar recente geopolitieke ontwikkelingen roepen steeds meer vragen op over de digitale soevereiniteit van Europa.

De herverkiezing van Donald Trump heeft de spanningen tussen Europa en de Verenigde Staten opnieuw aangewakkerd. Hoewel de VS een belangrijke bondgenoot blijft, groeit de zorg over onze bijna volledige afhankelijkheid van Amerikaanse cloudinfrastructuur – bij zowel overheden als bedrijven in heel Europa.

Een concreet voorbeeld van digitale afhankelijkheid

Die zorg werd heel tastbaar toen de regering-Trump actie ondernam tegen een hoofdaanklager van het Internationaal Strafhof in Den Haag en diens e-mailtoegang werd geblokkeerd.
Dat kon, omdat het Strafhof gebruikmaakt van Office 365 – een Microsoft-dienst die valt onder Amerikaanse jurisdictie en beleid.

Het incident toont een ongemakkelijke realiteit: onze digitale infrastructuur kan worden beïnvloed door buitenlandse politieke beslissingen, zelfs als Nederland daar geen directe rol in speelt.
Wanneer een bondgenoot zelfstandig essentiële digitale diensten kan uitschakelen, is dat een serieus risico voor onze digitale autonomie.

Wij zijn niet de enigen die deze afhankelijkheid zien. De website european-alternatives.eu – gelanceerd in december 2024 – zag een sterke toename in bezoekersaantallen (zie afbeelding hieronder). Dat laat zien dat de belangstelling voor Europese cloudalternatieven snel groeit.
Ook Bert Hubert, cybersecurity-expert en voormalig AIVD-toezichthouder, heeft herhaaldelijk opgeroepen tot actie om deze afhankelijkheid te verminderen.

Van politiek naar praktijk: tijd om te nerd-en

Hoewel geopolitiek de aanleiding was, zijn we uiteindelijk techneuten – dus we deden wat we het liefst doen: we gingen zelf aan de slag.

We maken momenteel vooral gebruik van Azure, met af en toe een uitstapje naar AWS of Google Cloud. Om alternatieven te kunnen vergelijken, moesten we eerst bepalen welke functies voor ons essentieel zijn.

Met onze DevOps-focus op Kubernetes werd al snel duidelijk waar het om draait. Naast container orchestration gebruiken we Azure Functions en verschillende dataservices. En ja, onze CTO heeft nog steeds die ene Java-applicatie draaien voor €0,01 per maand.

Na ons overleg kwamen we tot deze kernfuncties van een cloudplatform:

Netwerk (publieke IP’s, routing, firewalls, load balancing)

Met european-alternatives.eu als startpunt vonden we op dat moment 12 Europese providers – en het aantal groeit snel. Drie sprongen er meteen uit:

OVH Cloud – Gevestigd in Frankrijk, gesteund door de Franse overheid, en nu ook beschikbaar voor publieke organisaties.

Stackit – Een Duitse provider in handen van de Schwarz Group (het moederbedrijf van Lidl en Kaufland), vaak met een knipoog “LidlCloud” genoemd.

Cyso Cloud – Gevestigd in Nederland (voorheen Fuga Cloud), met lokale hosting en vertrouwde regelgeving.

Onze collega Noud testte de Kubernetes-mogelijkheden van OVH Cloud. De resultaten waren positief: eenvoudig op te zetten, goed gedocumenteerd en prima performance.
Met Terraform draaide hij succesvol een Kubernetes-cluster uit met de OVH-provider. De uitrol van een simpele nginx-app werkte vlekkeloos.
Een kleine kanttekening: de benaming van regio’s zou wat intuïtiever mogen zijn – dat zou migraties vergemakkelijken.

Dion ging aan de slag met Stackit, wat iets complexer bleek. Stackit was oorspronkelijk bedoeld voor intern gebruik binnen de Schwarz Group en is niet volledig publiek beschikbaar.
Na contact met Stackit-engineers op KubeCon London kregen we toegang. Het platform draait op OpenStack en biedt compute-, storage- en Kubernetes-infrastructuur. De enterprise-achtergrond is duidelijk zichtbaar. Verdere tests volgen binnenkort.

Onze CTO Bouke nam de proef op de som en probeerde zijn wekelijkse Java-applicatie van Azure Functions naar een Europees alternatief te migreren.
Dat bleek lastiger dan verwacht: Java-support ontbreekt vaak, en sommige aanbieders vereisen dat scripts binnen Kubernetes draaien – wat de kosten flink verhoogt voor simpele taken.
Dit wijst op een groeimogelijkheid: meer taalondersteuning en eenvoudigere serverless-opties in de Europese cloud.

Op basis van onze eerste verkenning hebben we drie vervolgstappen gedefinieerd:

Diepgaand technisch onderzoek – Binnen enkele maanden plannen we een tweede sessie waarin we meerdere Europese providers grondig testen met echte workloads.

Kennisdeling – We willen onze bevindingen publiek delen, zodat ook anderen kunnen leren over de stand van de Europese cloud.

Praktische voorbereiding – Geen overhaaste migraties, maar een strategische positie om goed onderbouwde keuzes te kunnen maken zodra de tijd rijp is.

Europese cloudproviders lopen qua functionaliteit en ecosysteem nog achter op de “grote drie”.
Toch zien we veelbelovende ontwikkelingen: de basisdiensten zijn volwassen, en steeds meer providers breiden hun portfolio uit met specialistische oplossingen.

Wat Europese aanbieders wél bieden, is iets dat steeds waardevoller wordt: volledig Europese hosting met ingebouwde naleving van Europese regelgeving en privacywetgeving.
Het gaat dus niet alleen om datasoevereiniteit, maar ook om voorspelbaarheid en onafhankelijkheid.

Conclusie: voorbereid op meerdere scenario’s

We verwachten niet dat bedrijven massaal morgen overstappen van Amerikaanse naar Europese clouds. Zulke migraties vergen tijd, planning en overtuiging.
Maar bij CINQ willen we voorbereid zijn op verschillende scenario’s:

Klanten die bewust kiezen voor Europese hosting

Nieuwe regelgeving die Europese dataopslag vereist

Geopolitieke spanningen die toegang tot Amerikaanse clouds beïnvloeden

En natuurlijk: blijven waar het nu nog het beste past

De kern is voorbereiding: weten wat er speelt, de alternatieven kennen, en technisch klaarstaan om te handelen wanneer het moment daar is. Of dat volgend jaar is of over vijf jaar – wij zorgen dat we er klaar voor zijn.

Onze engineers onderzoeken Europese cloudalternatieven voor Amerikaanse providers. Lees wat we ontdekten over soevereine cloudinfrastructuur.

EU Cloud: Onze eerste ervaring met Europese cloudproviders

Onze eerste ervaring met Europese cloudproviders

Our engineers recently gathered to discuss a topic that's becoming increasingly urgent: sovereign cloud infrastructure. Our conversation covered cloud solutions in Europe, the Netherlands' digital independence, and our current reliance on American cloud providers. This blog post shares the key insights from that meeting and outlines our planned next steps.

Our discussion began with an observation that's hard to ignore: media coverage consistently focuses on the "big three" American cloud providers - Microsoft Azure, Amazon Web Services, and Google Cloud. While these platforms dominate the market, recent geopolitical developments have raised important questions about Europe's digital sovereignty.

The re-election of Donald Trump has introduced new tensions in European-American relations. While the United States remains a valued ally, our almost exclusive dependence on American cloud infrastructure is becoming a point of concern for many organizations and governments across Europe.

A Real-World Example of Digital Dependency

This concern moved from theoretical to concrete when Trump's administration took action against a Chief Prosecutor at the International Criminal Court in The Hague, blocking access to email services. This was possible because the ICC relies on Office 365 - a Microsoft service subject to American jurisdiction and policy decisions.

The incident illustrates a troubling reality: our digital infrastructure can be disrupted by foreign policy disagreements, even when those disagreements don't directly involve us. When an ally can unilaterally disable critical services we depend on, it raises serious questions about our digital autonomy.

We're not alone in recognizing this challenge. The website european-alternatives.eu, launched in December 2024, has seen a significant surge in traffic (as shown in image below), indicating growing interest in European cloud alternatives. Additionally, cybersecurity expert Bert Hubert a former AIVD supervisor and employee - has repeatedly called on the Dutch government to address this digital dependency.

From Politics to Practice: Time to Nerd Out

While geopolitics sparked our initial interest, we're technical people at heart - so we did what we do best: we rolled up our sleeves and started exploring the technical landscape.

Since we primarily use Azure (with occasional AWS and Google Cloud deployments), we first needed to identify which functionalities are essential to our operations. Given our DevOps team's focus on Kubernetes, the answer became clearer. Beyond container orchestration, we also rely on Azure Functions and various data services. And lastly our CTO still has that Java applet running weekly for €0.01 per month.

After our discussion, we identified these core cloud platform functions:

Networking (public IP addresses, routing, firewalls, load balancing)

Using european-alternatives.eu as our starting point, we found 12 alternative providers listed at the time of writing - a number that continues to grow. Three stood out immediately:

OVH Cloud: Hosted in France and trusted by the French government, now available to public companies. Their established presence and government backing caught our attention.

Stackit: Primarily hosted in Germany and owned by the Schwarz Group (which also owns Lidl). Sometimes playfully called "LidlCloud," this platform has serious enterprise backing.

Cyso Cloud: Based in the Netherlands and formerly known as Fuga Cloud, offering local hosting with familiar regulatory frameworks.

Hands-On Testing: Our Initial Experiments

Our colleague Noud took the lead on testing OVH Cloud's Kubernetes capabilities. The results were encouraging - deploying applications proved straightforward and user-friendly. Using Terraform, he successfully spun up a Kubernetes cluster, leveraging OVH's dedicated Terraform provider to create the necessary resources efficiently.

After deploying a simple nginx application to the cluster, everything worked as expected. The sign-up process was smooth, and deployment times were reasonable. One minor observation: the region naming conventions could be more intuitive, which would simplify initial setup and potential migrations from other providers.

Our colleague Dion began exploring Stackit, though this proved more complex initially. Unlike other providers, Stackit isn't open to the general public - it originated as an internal cloud solution for the Schwarz Group's companies, including Lidl and Kaufland.

Dion connected with Stackit engineers at KubeCon London in April, and we received access just after our session was held. The platform shows significant promise, built on OpenStack for compute, storage, and Kubernetes infrastructure. Their enterprise heritage suggests robust, scalable solutions. We will be testing this soon.

Our CTO Bouke set himself an interesting challenge: migrating his weekly Java applet from Azure Functions to a European alternative. This seemingly simple task revealed some current limitations in the European cloud ecosystem.

While several alternatives offer script scheduling capabilities, Java support remains limited. Other providers require running scripts within Kubernetes clusters, which significantly increases costs for simple, infrequent tasks. This highlighted a potential path forward: adapting to different programming languages to better align with European providers' current offerings.

Based on our initial exploration, we've outlined several concrete next steps:

Deeper technical evaluation: We're scheduling another session in a few months, with teams assigned to thoroughly test each promising cloud provider. This will give us hands-on experience with real-world workloads.

Knowledge sharing: We're planning to make our findings public through an open session, sharing our discoveries with the broader technical community and demonstrating what's already available in the European cloud landscape.

Practical preparation: Rather than advocating for immediate wholesale migration, we're positioning ourselves to support informed decisions when the time comes.

European cloud providers are undeniably behind the "big three" American companies in terms of feature breadth and ecosystem maturity. However, the services we've examined show genuine promise for core functionalities, and some are already expanding into more specialized areas.

What European providers offer that their American counterparts cannot is something increasingly valuable: native European hosting with built-in compliance to European standards and regulations. This isn't just about data sovereignty - it's about predictable, stable access to critical infrastructure.

The current momentum is encouraging, with interesting developments happening at both the technical and governmental levels. However, we're realistic about the timeline ahead.

Conclusion: Prepared for Multiple Scenarios

We don't expect massive migrations away from American cloud providers in the immediate future. Enterprise migrations require significant time, effort, and planning. Political landscapes change, and many organizations are comfortable with their current solutions.

But as CINQ, we're preparing for various scenarios:

Customer-driven moves to European cloud solutions

Regulatory requirements that favor European hosting

Geopolitical disruptions that affect American cloud access

Continued reliance on current providers where appropriate

The key is being ready: understanding the landscape, knowing the alternatives, and having the technical expertise to advise and implement when the time comes. Whether that's next year or in five years, we'll be prepared to help our clients navigate whatever the future of cloud infrastructure brings.

Discover why sovereign cloud matters more than ever. Learn about Europe's digital independence, the risks of U.S. cloud reliance, and our hands-on tests with OVH, Stackit, and Cyso as promising European cloud alternatives.

Why sovereign cloud matters more than ever

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, Development en Quality. Wij geloven in specialisten, vandaar de vier specialismen Data, DevOps, Development en Quality 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

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: 

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 Rijkswaterstaat.

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 vier 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.

Bij ons 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 € 6.500, afhankelijk van je kennis en ervaring.

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

een ruim ontwikkelbudget voor trainingen en certificeringen

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.

bezoek conferenties zoals JavaOne, Devoxx en JFall.

flexibiliteit om thuis, bij ons op kantoor en bij de klant te werken

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.

minimaal 5 jaar werkervaring met Java en/of Kotlin

ervaring met relevante back-end frameworks zoals Spring Boot

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. 

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.

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

Back-end developer

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

36 - 40 uur per week

Back-end Developer

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:

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

komen met verbetervoorstellen richting de klant.

CINQ is opgesplitst in vier 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. 

Bij ons krijg je 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.500, afhankelijk van je kennis en ervaring.

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

flexibiliteit om thuis, bij ons op kantoor en bij de klant te werken


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.

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

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

Splunk Engineer

Als Splunk specialist help jij verschillende grote bedrijven om meer waarde uit hun data te halen.

Jij houdt ervan als data klopt. Als datastromen logisch en efficiënt verlopen, zonder overbodige ruis of onnodige kosten. Jij snapt dat goede observability of security begint bij de bron, en dat slimme datarouting met Cribl essentieel is om grip te houden. Daarom ben jij dé specialist die ervoor zorgt dat data alleen dáár terechtkomt waar het waarde toevoegt — verrijkt, gefilterd en onder controle.

Geen dag is hetzelfde, want iedere klant heeft weer een andere omgeving, andere uitdagingen en andere doelen. Jij vindt het leuk om daarin te schakelen, mee te denken en creatieve oplossingen te bedenken

Als Cribl specialist ben jij de expert in het beheren van data aan de bron. Je werkt aan uitdagende klantprojecten waarin je:

Cribl Stream of Edge inzet om datastromen te filteren, routeren en transformeren;

Integraties maakt tussen logbronnen, securityplatformen, monitoringtools en storageoplossingen;

Meewerkt aan proof of concepts, optimalisaties en nieuwe implementaties;

Klanten adviseren hoe zij efficiënter met hun data om kunnen gaan en daar meer waarde uit kunnen halen;

Continu zoeken naar verbeteringen: efficiënter, schaalbaarder, slimmer.

CINQ is opgesplitst in vier 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 Observability 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. 

een brutomaandsalaris tussen € 42.00 en € 6.200, afhankelijk van je kennis en ervaring.

Jij bent een doener met visie. Je snapt wat er technisch nodig is, maar denkt ook in klantwaarde. Je bent technisch sterk en ook in staat om dat goed over te brengen naar klanten en collega’s. Je bent leergierig, zelfredzaam en altijd op zoek naar de nieuwste tools en technieken om je werk nog beter te doen. Verder:

Kun je zelfstandig een Cribl-omgeving ontwerpen, inrichten en beheren;

Heb je ervaring met Cribl (Stream, Edge, Search) of vergelijkbare tools voor datarouting (bijv. Logstash, Fluentd, Vector);

Weet je hoe logformaten (zoals syslog, JSON, CEF) in elkaar steken;

Haal het maximale uit data voordat het ergens terecht komt als Cribl engineer.

Cribl Engineer

Haal het maximale uit data voordat het ergens terecht komt

17 november: Europese Cloud Meetup

Presentaties

Programma

Locatie

Aanmelden

Meer blogs

“No pass, no entry” - a musician’s take on JWTs

Onze eerste ervaring met Europese cloudproviders

Why sovereign cloud matters more than ever