On 25 September 2025, the second day of TechEx Europe at the RAI in Amsterdam, I spent the early afternoon on the expo floor with a microphone. TechEx puts several expos under one roof, among them AI & Big Data, Cyber Security & Cloud, IoT Tech and Edge Computing, so in three hours I went from a CISO panel to model compression to industrial gateways.
My autumn 2025 Amsterdam roundup has a short TechEx section. This post covers the conversations in full: eight short interviews at six companies. Each section says what the company does, as the person at the booth explained it on camera, the answer I found most interesting, and my own view as a platform engineer. I don’t name the people I spoke to unless I could confirm their name on an official page. Product claims are the vendors’ own, and I’ve linked their documentation.
The TechEx letters at the RAI, between booth visits.
Cloudflare: the changing role of the CISO
I started at the Cloudflare booth with one of their field CISOs, who had just come off a panel about how the CISO role is changing. We recorded two takes, and this section combines them.
He summed up Cloudflare’s portfolio in three verbs: connect, protect and build. The company started as a content delivery network, and that network became the base for everything else: anti-DDoS, web application firewalling, zero trust network access, email security and data loss prevention. The newest layer is the developer platform built around Workers, where, according to him, developers can build applications and call the major AI model providers through Cloudflare. He also said that because everything runs on the same global network, your code ends up close to your users, within about 50 milliseconds. Cloudflare’s network page says 95% of the world’s Internet-connected population is within 50 ms of one of its data centres.
The panel topic was the more interesting part. He described a role that has grown a lot. Five or ten years ago, if you asked a CISO who secured the factory automation or IoT, the answer was someone in engineering. Who secured the supply chain? Someone in procurement. Now both belong to the CISO. With AI, he said, the job is moving from “no, that’s outside policy” to “this is how we can use it securely”, and the goal is trust with stakeholders, which covers responsible and ethical AI as well as security. On Cloudflare’s side, he pointed to its gateway for AI and APIs and its guardrails. The AI Gateway docs describe analytics, caching, rate limiting and model fallback, and Guardrails checks prompts and responses for harmful content.
He also had a warning about the order in which companies adopt AI. You should start from a business case and let the technology serve it, but many organisations do the opposite: “It’s AI first, and then we want to look for a problem that it can solve.”
The back wall of the Cloudflare booth: “Protect People, Apps, AI, Traffic, Cloud, Email. Everywhere.”
My take: “from no to how” is the same change platform teams went through with Kubernetes. Security teams that only say no end up with shadow IT, and with AI that means shadow API keys. The answer is to make the safe path the easy one. An AI gateway that every team calls by default gives you logging, cost control and guardrails without a ticket queue. I described the self-hosted version of that pattern in AI gateways on Kubernetes.
Cloudflare: CAPTCHAs, zero trust and record DDoS attacks
A few minutes later I spoke to another member of the Cloudflare team, who had also joined the company recently. He started with the map on the booth wall. The wall said roughly 20% of the web is protected by Cloudflare, and the company’s own figure is “1 in 5 sites on the Internet”. That reach is why, he said, so much information flows through their systems.
When I brought up CAPTCHAs, he agreed they’re annoying but said they’re necessary. Access decisions depend on who you are, which device you’re using and where you’re connecting from, and those signals are what Cloudflare’s zero trust is built on.
Then he talked about DDoS records, which were climbing fast that month. He mentioned an attack of about 11 terabits per second, then one of about 22 Tbps lasting 40 seconds, seen just that week. Cloudflare announced that week that it had mitigated a 22.2 Tbps attack lasting 40 seconds, a few weeks after an 11.5 Tbps record. (The transcript says “terabytes”, but the published figures are in terabits.) He described the developer platform in one line: “Coders should spend their time coding.”
My take: a 40-second attack at 22 Tbps is over before anyone gets paged. At that scale, mitigation has to be automatic and sit in front of your infrastructure. If you run your own ingress on Kubernetes, rate limits and WAF rules in the cluster are still worth having. They just aren’t what stops a volumetric attack.
Redamp.io: a security bundle for SMEs
In the Brno region pavilion, someone from Redamp.io, a Czech security startup, explained the problem they’re solving. To be reasonably protected, a small or medium business would need to buy eight to ten products from different vendors. Most can’t afford that, so they buy one and leave the other gaps open. Redamp.io bundles those functions into one affordable SaaS product that “works out of the box”.
When I asked how it works, he described the onboarding. You register an account in about five minutes, then install the apps on your devices, either by hand or automated. Within about ten minutes you can see what’s happening in your environment. The platform ranks issues by priority so you can fix them one at a time, and according to him, it solves many of them for you. The official site lists device protection, network monitoring, patch management, data breach alerts, phishing simulations and NIS2 compliance guidance, with a free trial.
My take: this is platform engineering for companies that have no platform team. Good defaults, automation and one dashboard matter more than features to a ten-person firm. The trade-off is the usual one with a single vendor: one agent on every device and one console with a lot of power. Before you deploy, ask how updates to the agent are rolled out and what happens if the console account is compromised.
AIminify: compressing computer-vision models
At AIminify, I spoke to someone from the team next to a laptop running a live object-detection demo. AIminify compresses computer-vision models that are too big or too slow to deploy, especially on edge devices. You run it with one line of code. It detects the filters and layers in the model and applies pruning and quantization, then you fine-tune the result. It runs on-premises, so your model doesn’t leave your environment. According to AIminify, the optimised model can be up to 10 times faster and up to 4 times smaller, and those are the same figures that are on their website.
The demo used a standard YOLO model optimised with their tool. He contrasted it with the unoptimised model, where the detections jump from frame to frame. When I asked about scope, he said it’s computer vision only: vision transformers work, LLMs don’t, because “it’s hard enough to automate the computer vision part already.” He also said they don’t recommend specific hardware. Some customers want a cheaper GPU, some want to run on CPU instead of GPU, and some want to shrink a model until it fits on a Raspberry Pi.
AIminify’s banner: “AI compression – in one click”.
My take: I like that it doesn’t try to do everything. Treat a compressed model as a build artifact: run the compression in CI, version the output next to the original, and add an accuracy check on your own validation set as a release gate. “Up to 10x faster” depends heavily on the model and the hardware. I covered the trade-offs in INT4 and INT8 quantization for edge AI.
Ververica: Flink, Paimon and Fluss
At the Ververica booth, a team member gave me the short version first. Spark is your batch engine and Apache Flink is your streaming engine. Both projects started around the same time, with different philosophies. With Flink you can act on an event the moment it arrives instead of minutes later in a batch job. His example was card fraud: if your card is swiped in Amsterdam and, a few seconds later, somewhere on the other side of the world, you want to block the transaction now, not five minutes from now.
He described Ververica as the company behind Flink. It maintains the open-source project and sells a platform that takes away the pain of running it yourself: change data capture, the processing engine, and Apache Paimon as lake storage, with integrations for formats such as Iceberg. The part he was most excited about was Apache Fluss. As he explained it, Flink writes incoming data straight into Fluss, which acts as a hot layer you can run lookups against, while historical data lives in the lake. You query hot and cold data together, so your analytics always see fresh data, and Fluss adds the persistence Flink lacks on its own. According to him, that means many teams no longer need Kafka in front of Flink. The Fluss project calls itself “Streaming Storage for Real-Time Analytics & AI”, with primary-key tables for key/value lookups and tiering to lake formats such as Paimon and Iceberg.
Ververica’s roll-up: “Unified Streaming Data Platform. Built for Real-Time Intelligence and AI”.
My take: “you don’t need Kafka anymore” is true for one path, from ingest to analytics. In most companies, though, Kafka is also the integration bus that a dozen other services consume from, and that won’t go away. What does appeal to me is having fewer copies of the same data. Every copy between Kafka, a cache and the lake is another pipeline to monitor, another schema to keep in sync and another bill. I wrote about the schema side in streaming and unifying schemas with CDC.
A Ververica partner: shift-left data quality
At the same booth I spoke to a consultant from a Ververica partner consultancy who has worked with Flink for five or six years. When I asked about latency, he said it depends on how complex your logic is, but you can aim for around 100 milliseconds.
One of his favourite projects was a real-time, omnichannel customer engagement platform he helped build as a SaaS product at a previous startup. It collected every customer interaction as it happened, inferred the customer’s intent, picked a strategy (cross-sell, upsell or churn prevention), called the ML and AI models, and returned the “next best action”. All of that had to finish within one second.
His main point was about data quality. Most of the market tries to fix bad data downstream, after it has already reached the warehouse and every application that consumes it. He argued for shifting left: check quality at the source, and move from batch-based data exchange to event-driven architecture. In his model, Kafka carries the data and Flink is the smart endpoint where the processing and the intelligence happen.
My take: shift-left data quality is the same idea as admission control in Kubernetes. Reject the bad object at the API server and you don’t have to clean it out of fifty controllers later. Schema registries and data contracts enforced in the stream do for events what OPA or Kyverno policies do for manifests.
Snowflake: dbt projects and Cortex AI
At Snowflake, a solutions engineer gave me the overview. Snowflake is a managed cloud data platform that runs on AWS, Azure or Google Cloud. You use it for data engineering, analytics, AI and applications on company data you’ve centralised in one place. The pitch is the three words on the booth wall: easy, because it’s managed and you don’t have to stitch tools together yourself; connected to the rest of the ecosystem; and trusted, through governance and security.
On dbt, he said many customers use dbt Cloud connected to Snowflake, and there are now also dbt projects built natively into Snowflake. Snowflake’s docs describe dbt Projects on Snowflake as a way to “develop, deploy, orchestrate, and observe” dbt transformations inside the platform. For AI, he walked through Cortex AI: LLMs hosted natively in Snowflake, Document AI to extract information from documents, chunking and vectorising so you can chat with those documents, and, for structured data, semantic models that describe what the tables mean for the business, so an LLM can answer questions about them. That last part is what Snowflake documents as Cortex Analyst with semantic views. He also mentioned free trial accounts on all three clouds and the step-by-step quickstart guides.
The Snowflake booth: “AI Data Cloud”.
My take: the semantic model is where the real work is. An LLM can only answer “what was revenue last quarter” correctly if someone has written down what “revenue” means. That’s a data modelling job, not an AI job. Running the model next to the data is mostly a governance win: no copies of sensitive tables in a separate vector store with its own access rules. I saw Cortex for the first time at Snowflake World Tour Amsterdam 2024.
AAEON: a “Raspberry Pi on steroids” for the factory floor
My last stop was AAEON, where their sales manager for the Benelux walked me through the IoT range. AAEON makes industrial smart gateways that connect to sensors. An entry-level gateway collects the data and sends it to the cloud. A more powerful one can pre-process the data, or even host a whole dashboard, on the gateway itself. In his words, it’s edge computing instead of cloud computing.
I asked how these compare with a Raspberry Pi, since most of my audience knows one. He called their board a “Raspberry Pi on steroids”: it uses an Intel x86 processor but keeps the Raspberry Pi’s 40-pin connector, so Raspberry Pi accessories still fit. A Raspberry Pi is ideal for a proof of concept, he said, but an industrial deployment has to handle temperature, shock and vibration without downtime, so it needs a ruggedised board. His example of where the edge is necessary: on a high-speed production line, a sensor reading has to trigger an action within milliseconds, and there’s no time to send it to the cloud, compute and send the answer back. On Linux, he said they support Yocto as well as Debian and Ubuntu. He also mentioned AAEON’s UP brand, whose boards advertise a 40-pin header.
AAEON’s booth wall, and the display of compact systems and bare boards next to it.
My take: x86 with a Raspberry Pi pin layout is a practical combination for platform teams. You get the same container images and the same tools on the factory floor as in the data centre, without cross-compiling for ARM, and the existing HATs still work. Add k3s or KubeEdge and the gateway becomes one more node in your fleet, managed through GitOps. I went through that setup in edge AI with Kubernetes.
What the afternoon added up to
Eight conversations, and most of them were about where computation runs and how much data gets copied: inference squeezed onto smaller hardware, decisions made on the gateway rather than in the cloud, streams that serve lookups without another cache, and LLMs running next to the data. Security came up in the same way, as guardrails built into the path rather than a gate at the end.
