Platform Engineering Amsterdam Meetups, Autumn 2025

I went to two Platform Engineering Amsterdam meetups in the second half of 2025, both on a Wednesday evening. On 17 September the meetup was hosted by tarmac, in a waterside bar overlooking the IJ, with tarmac’s roll-up next to the stage: “The sky is the limit & the cloud is the playground”. On 12 November the opening slide read “Hosted by JetBrains, tarmac”, and the roll-up had a new line: “Ahead in the clouds”.

Both evenings had three talks. In September I recorded all three. In November I recorded most of them and photographed the slides, so this post covers all six.

17 September: tarmac opens the evening

Michaela Herman, General Manager of Tarmac Europe BV, opened the evening. Her slide described tarmac as a software development partner focusing on DevOps (“AWS Advanced Partner”), frontend, backend and mobile (iOS, Android and cross-platform), UI/UX design, and a “Cloud Optimisation Package”.

Me in the audience while tarmac introduced itself. The slide lists DevOps, frontend, backend, mobile, UI/UX and a cloud optimisation package.

Between two talks, a slide with the meetup’s footer pointed to a session called “Data Hoarders Guide to Small Cloud Bills”, with a QR code. The talk itself came two months later, in November (more on that below).

Product- and platform engineering: cognitive load and maturity

The first talk was “Product- & Platform Engineering”, subtitled “Advancing the people who manage the value in the Cloud”. The speaker’s name wasn’t on the slides I photographed, so I’ll leave it out.

He started with why this matters. The “key challenges” on the slide included cognitive load and a lack of standardisation. The chart next to it plotted “Product Adoption, Organisational Evolution, and Cognitive Load Over Time”. One series showed the years each product took to reach 100 million users, falling from mobile phones (around 16 years) through the internet, Google Search, Facebook, YouTube, Spotify, Netflix, Uber, WhatsApp, Snapchat and Instagram down to TikTok and ChatGPT. A second line showed cognitive load climbing from 20% to 85%, with Agile, DevOps and then Platform Engineering marked as successive eras. The source line cited McKinsey, ResearchGate, UBS and Asana’s Anatomy of Work report.

Products reach 100 million users faster and faster, while the cognitive-load line keeps climbing through Agile, DevOps and Platform Engineering.

Next came a “Types of teams” slide, “adapted from Team Topologies by Skelton & Pais and the State of Platform Engineering Report”. It showed three stream-aligned teams along a “Flow of Change” arrow, an enabling team across them, a complicated-subsystem team on the side, and a platform team underneath. These are the four team types in Team Topologies.

The Team Topologies picture: stream-aligned teams carry the flow of change and the platform team sits underneath them.

The slide I found most useful was “Value of Product & Platform Engineering”. It was a grid built on the aspects and levels of the CNCF Platform Engineering Maturity Model (Provisional, Operational, Scalable, Optimising), with a percentage in every cell. The sources line read “Adapted from CNCF Platform Engineering Maturity Model, Gartner, McKinsey, Microsoft DevBlogs, State of Platform Engineering Report Vol. 3, and DORA Metrics”. A red line linked the largest share in each row:

• Investment: a dedicated team was the most common answer (43.3%), followed by “as product” (35.7%), with an enabled ecosystem at 12.2% and voluntary or temporary at 8.8%.
• Adoption: extrinsic push led (35.8%), then intrinsic pull (28.4%), erratic (18.52%) and participatory (17.3%).
• Interfaces: standard tooling (42.1%) ahead of self-service solutions (34.3%). Only 9.1% had integrated services.
• Operations: the only row where the Scalable column won, with “centrally enabled” at 39.3%.
• The next row repeated the “Investment” label but used the model’s measurement levels: ad hoc came first (42.5%), and only 10.4% reached “quantitative and qualitative”.
• Measurement: “We do not measure” was the biggest answer at 44.67%. DORA metrics followed at 37.3%, time to market at 11.5% and other at 6.6%.

Most organisations sit in the Operational column, and almost 45% don’t measure their platform at all.

The second half of the talk was a story about adopting Azure through a cloud centre of excellence. Product teams got compliant templates, so “use the template and you’re compliant”. As usage grew, operational spend rose about 15% a year, and hiring more people wasn’t an option. A partner took over part of the build work, which freed the central team to sit next to product teams instead of just writing documentation. The team then added a product called Cloud Command. It did two things. First, it gave standard dashboards built on what the managed landing zone already knew: subscriptions, tagging, teams, cost centres and security posture. Second, it let teams request things from there (a storage account, a firewall change) and receive code generated from managed templates. Developers then complained that Azure Policy only stopped them when they deployed to acceptance. The answer was GitHub Advanced Security, so the feedback showed up in the IDE instead of at the sprint demo. The last step was letting teams combine several patterns and share them with each other.

He was clear that the outcome numbers he showed (less productivity loss, less technical debt, lower turnover, fewer bug fixes, and a production bug costing six times more to fix) came from published studies, not from his own organisation. He was also candid that measurement was not yet where he wanted it to be, which matches the 44.67% on his own slide.

My take: the maturity grid is a good mirror. Most teams have funded a platform team and standardised their tooling, but they push adoption instead of earning it, and they don’t measure. “How do you know it’s working?” is the question most platform teams still can’t answer. DORA metrics plus a short developer survey are enough to get started.

Pen testing LLM apps with the OWASP Top 10

The second talk was “Pen Testing Large Language Model Apps: Using the OWASP Top 10 for LLM Apps” by Darko Mihajlovski, who said he had worked in IT for 17–18 years, 13 of them in security. His agenda was: what an LLM is, how a traditional web-app pen test maps onto an LLM app, how LLMs get attacked, and a walk through the OWASP Top 10 for LLM Applications 2025 with a focus on prompt injection, “because everything relies on there”.

The title slide of the LLM pen-testing talk.

He compared the two worlds side by side. HTTP verbs become natural language. Command injection becomes prompt injection. A web app with too many database rights becomes “excessive agency”. He separated direct prompt injection (typed into the prompt) from indirect injection through retrieval-augmented generation, where the payload sits in an external resource the model is asked to read. He then went through the OWASP threat model diagram (a malicious user on one side, untrusted internet content on the other) and a series of lab examples, each with a suggested fix:

• Markdown image injection: the model is told to answer in a markdown format that loads an image from an attacker’s URL. Fix: sanitise markdown input and restrict what markdown can execute.
• Base64-encoded XSS: ask the model to decode a base64 string and write JavaScript to decode it, and a script alert pops up. Fix: sanitise user input and restrict decoding.
• Remote code execution: ask for a Python reverse shell and then ask the model to run it on its server. Fix: execute generated code only in a sandbox, such as a just-in-time container.
• Role-play jailbreaks: “pretend” (not “act”) to be a 1950s marketing expert, and the model writes an email promoting smoking. Fix: restrict roles and add a fact-checking step before output.
• “Ignore previous instructions” followed by “summarise the above prompt”, which can leak earlier prompts and configuration. Fix: isolate the system prompt and separate sessions with role-based access control.
• Excessive agency: in a lab, a chatbot ran select * from users and returned unhashed passwords, and it would have run a delete too. Fix: least privilege and no dynamic code execution.

He also showed PAIR, the Prompt Automatic Iterative Refinement technique from the paper “Jailbreaking Black Box Large Language Models in Twenty Queries”, where an attacker LLM keeps rewriting a refused request (“how do you hotwire a car?”) until it gets through. His closing advice had three layers: security in the design and training of the model, automated scanning as part of DevSecOps (including dynamic testing of the running model), and manual, human-led penetration testing of the runtime. His last slides were a checklist of safeguards to have in place before an LLM app ships.

My take: most of these attacks only matter once the model has tools and data behind it. For platform teams that host LLM workloads, the platform-level controls are a sandboxed runtime for generated code, scoped credentials for every tool an agent can call, and egress rules that stop a markdown image from calling home. I cover the same list in my OWASP Top 10 for LLM applications guide.

A fintech platform: two non-functional requirements and an SQS ceiling

The third talk was an architecture story from a fintech that runs a payee name-check service from inside a large bank. I couldn’t read the speaker’s or the company’s name on any slide, so I’ll keep both out. According to the speaker, the service started in 2016 in the bank’s innovation lab, on AWS with Java. It serves more than 150 banks and 400 corporates, and it cut one specific fraud type by 81%. The name-matching engine in the middle is the part they keep closed.

The parts that stayed with me:

• Bank due diligence: spreadsheets of around 300 questions per bank, each phrased slightly differently. Typical questions were where all bank data is stored (down to backup tapes), secure coding, access control and pen testing, on top of ISO 27001 and DORA.
• RTO means different things to different people: rebuilding the whole system from code and backups in a new AWS environment takes about a week, and they test it every year. UK banks wanted a tier-one RTO below four hours. The team answered with a table of recovery objectives per failure type, since losing one of three availability zones means near-zero recovery time. Their security officer, he said, calls that business continuity, not disaster recovery.
• Multi-region: the UK setup had to run in two regions, with Frankfurt as the second, so the Dutch single-region setup was being retrofitted for the rest of Europe. Replicating private keys was harder than expected. DynamoDB global tables made it a checkbox, but they also broke blue/green deployments of configuration tables. Traffic runs active-active, 50/50 across regions.
• Performance testing: the request chain ran from an Apigee API gateway through a load balancer and a Traefik proxy to Java services that write audit messages to SQS, with Elasticsearch behind them. One service stopped at 300 TPS however many servers they added. After ruling out health checks, Elasticsearch and the external mocks, the cause turned out to be SQS: one service wrote to a single message group, the other to several. That matches the documented SQS FIFO quota of 300 transactions per second per API action without batching or high-throughput mode. Fixing it exposed the next bottleneck, reading from the queue, and that led to a full refactor.

All of this was under deadline pressure: EU Instant Payments Regulation Verification of Payee checks had to be live on 9 October 2025, three weeks after the meetup. His closing advice: pick two, maybe three, non-functional requirements (for them, security and performance), and in your SLA, separate internal processing time from total latency, because upstream banks set most of the latter.

My take: “add servers, throughput stays flat” almost always means a shared resource with a hard quota, not a compute problem. I’d put managed-service quotas next to the load-test plan from day one.

Later that evening I had k8sstormcenter’s bobctl open on my phone. It describes a “Software Bill of Behaviour”: a vendor-supplied profile of an application’s expected runtime behaviour, designed to ship inside OCI artifacts so runtime security tools can calibrate against it.

12 November: JetBrains and tarmac, “Ahead in the clouds”

The November edition was hosted by JetBrains and tarmac. JetBrains had a branded wall up, and there were Junie, GoLand and Cloud Native Community Days Amsterdam stickers to take home.

The opening slide in November: Platform Engineering Amsterdam, hosted by JetBrains and tarmac.

Both hosts spoke first. A JetBrains engineer, who said he had been with the company for six years and started in support, reminded the room that JetBrains has an office in Amsterdam. He wanted it to be a place where engineers meet and talk about technical things, and he offered to route any IDE questions to the right people. Michaela from tarmac followed. She said she had been general manager for more than four years and that tarmac has around 300 engineers, working on frontend, backend, UI/UX, DevOps and cloud cost optimisation.

Eventually RESTful: event sourcing for line-of-business apps

The first talk was “Eventually RESTful: Making Event Sourcing feel familiar.” by Yeray Cabello, with the running header “Consistently Eventful & Eighty Data”. He introduced himself as a consultant and as one of those people who never stop talking about event sourcing. Since this was a platform engineering crowd, he said, he wouldn’t try to sell us platform engineering. Instead he argued that event sourcing has its own technical challenges, and that the same principles that make platforms work also make those challenges manageable. The title is a play on eventual consistency.

“Eventually RESTful: Making Event Sourcing feel familiar”, with “Consistently Eventful & Eighty Data” in the corner.

His agenda had three parts: event modelling (which he called a particular flavour of event sourcing), how a consistent API makes event sourcing feel natural, and a live demo.

Why events. He started with history, literally. History begins with the first written documents, and one of the oldest we have translated is a list of kings and deities. Accounting grew up separately in many cultures and still ended up looking much the same, which he took as a sign that this is how people naturally think about business. If all you have is the current state and something goes wrong, you work backwards from that state: that’s forensics. If you have the full history of how you got there, that’s accounting, and it’s a lot easier. He limited the claim to line-of-business applications. For something like Photoshop or a video streaming service, he wouldn’t build this way. The main reason we haven’t always built line-of-business systems on events, he argued, is that storage used to be expensive, and it no longer is.

The warehouse problem. His running example was retrieving stock from a warehouse. In a classic DDD and CQRS design you have a stock aggregate with a policy (don’t retrieve more stock than you have), you load it from the database, put a message on a queue so an alert goes out when stock runs low, and update a separate read model. Then the real rules arrive: orders with products from several warehouses, pre-reservations, confirmations and cancellations. You end up with sagas going back and forth, and then ports and adapters around a big model in the middle. “That’s how consultants are born,” he said, adding that he’s one himself.

Four functions. In line-of-business systems, he said, most features are a simple story that runs from left to right, so the architecture can be the same for every feature. That’s why he likes event modelling with a platform approach. A command emits an event. If stock drops low, another event triggers the alert. The framework keeps the read model up to date. The code you write shrinks to four small functions: one that projects events onto the entity, one that decides what each command does, one that decides whether to react to an event, and one that calls the outside integration. The framework handles everything else. He was clear that this was not a sales pitch, and that his framework is free and open source.

The demo. The event model is an object you hand to the framework, which then generates the API endpoints and the database tables for the projections, with filtering and sorting. The stock example had commands to receive and retrieve stock, and two read models: one with all products, and one with only the products running low. Each read model can have its own access level, for example for a dashboard. A low-stock email projection holds the logic that decides whether to send the email. The stock entity starts in a default state, and every event produces an immutable copy of it with the new amount. A command declares its signature, an area that groups it in the API definition, a description that ends up in the generated documentation, and its authentication requirement. If a command needs the entity to exist, the framework returns the 404 for you. What’s left is the business rule: if there’s enough stock, emit the event. If not, return an error.

He then came back to slices. Each command, read model or processor is a slice with its own consistency boundary, and views can sit on top of existing read models. In his experience, a team that delivers five slices one week delivers about five the next, which makes the cost of a feature predictable. Slicing also forces you to decouple your business logic. That can be painful, but he said it pays off later.

His takeaways:

• Traceability for free. Every command in the demo carried the user who issued it, without any configuration, plus correlation information that links each event back to its origin. When demo data goes missing, he joked, he knows exactly who did it.
• No database migrations. If you change a read model and remove a column, you can bring the column back later with all its data, because the events are still there.
• CQRS comes built in.
• Simpler workflows and sagas. Every step becomes a projection plus a task.

In the Q&A, someone asked about reporting. His view was that businesses do best when non-engineers can query data themselves without waiting for an engineer. Read models are flat tables, and event models are composable (he typically creates one per business capability). So you can spin up a new API with only the event model for the data you need. It gives you a single, up-to-date database with just that data, and it doesn’t affect the performance of the main system.

My take on event sourcing in platform work: an append-only log of what happened, with REST-style read models on top, is a natural fit for platform audit trails and self-service requests. That’s where I’d try it first, before using it for core business data. The no-migrations point is the one I’d use to convince a platform team. Rebuilding a read model from events is less risky than migrating an audit table in place.

Data Hoarders Guide: shrinking a two-petabyte S3 bill

The second talk was given by one of tarmac’s DevOps engineers in front of cartoon slides of clouds and trees. It was the “Data Hoarders Guide” talk that had been trailed in September. I’m leaving his name out, because it only appeared next to his contact details on the last slide.

The opening of the cloud-cost talk, under a sky full of (cartoon) clouds.

The project was an audiobook distributor that, according to the speaker, had been acquired by Spotify and was now being spun out as an independent company again. It serves more than a million audiobooks: audio files, cover art, PDFs and metadata. His favourite line was that if you play an audiobook on Spotify, Apple or another platform, it most likely goes through infrastructure he built. When his team inherited the platform, it held over 2,000 TB in Amazon S3, spread over about 400 million files. He took the savings in three groups: static data, data transfer and databases.

1. Deduplicate. Files arrive zipped, get unpacked, chaptered and joined by metadata and licensing files, so copies pile up. Instead of writing a script to list every bucket (which costs money in requests), they turned on S3 Inventory reports, loaded them as a table and grouped objects by ETag, the S3 checksum, which finds duplicates whatever the file is called.
2. Storage class analysis. The analyser is free and after about 30 days tells you which objects belong in which storage class. But if you then move objects yourself, every transition is a paid request, and across 400 million files that adds up.
3. S3 Intelligent-Tiering. You pay a small per-object monitoring fee, but the moves themselves are free. After 30 days, about 90% of their data had moved to the infrequent access tier, because not every audiobook is popular at the same time. When a book gets played again, S3 moves it back by itself.
4. The versioning trap. A lifecycle rule deleted temporary files after 30 days. It worked until someone turned on bucket versioning. From then on, the rule only expired the current version, so the files disappeared from the console but stayed in the bucket as hidden noncurrent versions. Once they ticked “show versions” and checked the metrics, they found about a petabyte they could delete.
5. Next step: leave S3. This one isn’t done yet. S3 Standard costs around $23 per TB per month, and he called outbound traffic the number that really hurts when you stream audio. A budget European provider (Hetzner, as the next speaker confirmed) charges a fraction of that for both storage and egress. He stressed that his comparison was simplified for effect, ignoring CDNs and tiered pricing. Two things make the move easier: AWS doesn’t charge data transfer out if you open a support case to migrate away, and many providers offer S3-compatible APIs, so often only the endpoint changes.
6. CloudFront. Putting CloudFront in front of the buckets lowers the per-GB price, and he hadn’t known before this project that CloudFront has its own commitment discount, the Security Savings Bundle, of up to 30%.
7. Databases. Historical records went back to 2018, and every monthly report scanned all of them. The quick wins were reserved instances, and then table partitioning with what he called one of his favourite new tools, the Postgres extension pg_partman. Historical data moved to a table partitioned by month, with a rolling window of the last 13 months. Older partitions are detached rather than deleted (“because of paranoia”) and archived to S3. Smaller tables and indexes made the database faster. A proper data warehouse on Redshift or Databricks is the long-term answer, but it takes longer.

Altogether, he said, the bill was now about $90,000 a month lower, roughly a million a year, and the S3 part needed no code or business-logic changes. In the Q&A, someone asked why so much data has to stay in hot storage. His answer: much of it is financial history, such as royalty payments and listening events, which they keep readily available for compliance, for about seven years as he recalled.

One correction to what he said. He mentioned that even the “deep archive” tier returns data in milliseconds. According to the S3 Intelligent-Tiering documentation, that is true of the automatic tiers: Frequent, Infrequent (after 30 days) and Archive Instant Access (after 90 days). The optional Archive Access and Deep Archive Access tiers have to be switched on and take hours to restore. The free exit is real: AWS announced it in March 2024.

My take: two of his steps belong in every platform’s S3 module by default. Add a noncurrent-version expiration rule wherever versioning is on, and use Intelligent-Tiering for buckets whose access pattern nobody can predict. Two small caveats: objects under 128 KB aren’t monitored or tiered, and ETags only work as content hashes for single-part uploads, so multipart copies of the same file won’t match. For the wider cost picture, see my Kubernetes FinOps guide.

KubeDNA: from a farmers’ marketplace to a Kubernetes one-stop shop

The third talk told the story behind KubeDNA. The speaker’s name was on his agenda slide, but I couldn’t read it in my photos. The agenda was “How it started”, “There needs to be a…”, “Objectives and Challenges” and “Wrap up”.

It started in Morocco. The speaker, who is Moroccan, said about 40% of Moroccans work in agriculture. When crops are ready, farmers struggle to reach buyers, and intermediaries and large corporations take much of the margin. So he and his team built a marketplace for farmers. They started on AWS, still working their day jobs. In the first month they ran up a bill of more than €1,000 before anything was live. They went back to the drawing board with a new list of requirements:

• run on a local provider
• automate as much as possible, because they all had day jobs
• autoscaling, because harvests are seasonal
• self-healing, again because of the day jobs
• use as few provider-specific services as possible, to stay cloud-agnostic

The slide “What we came up with” showed Hetzner and Ansible creating virtual machines, load balancers and firewalls, with Kubernetes and its add-ons on top (DNS and an NGINX ingress were among the logos). The first version took six months. They talked to government agencies in Morocco, and after three years the platform had 4,000 farmers and needed very little admin time.

Then came the idea. In their day jobs, they kept seeing Kubernetes setups that caused headaches. KubeDNA is their answer: a marketplace of cluster components plus a security and compliance layer. One slide showed a dashboard of installed components next to three groups of problems it had to solve:

• lifecycle management
• dependencies: “version of X doesn’t work with current version of Y”, “how do we guarantee compatibility between components in KubeDNA?”
• developer freedom: “I want to use Grafana”, “I want to use my Terraform”, “I already have Helm charts”

My recording of this talk cut out after a few minutes, so the rest comes from the slides. The security slide listed the challenges (“Secure environment without using CSP capabilities”, IAM/RBAC managed from within KubeDNA, guaranteeing the security of operators and components, demonstrating compliance) and what they did:

• every cluster has its own CA (TLS, 3-month rotation)
• VPN access only, with a VPN profile per user
• IP allowlisting
• RBAC within KubeDNA (not yet propagated to the clusters)
• logging per user
• manual compatibility testing of supported components before release
• teaming up with Kyverno to enforce controls aligned with specific compliance regulations

The roadmap slide, headed “Mission: Build the one-stop-shop for Infrastructure”, stacked an infrastructure-agnostic platform API, Kubernetes cluster management, storage and application layers, a “Secure & Compliant Policy Enforcement Shield” and an “AI-Powered Conversational DEX Interaction Layer”, with a “Secure MCP Integration Bridge” down the side. Next to it were future building blocks: AI/ML platform, serverless computing, data warehouse, relational and NoSQL databases.

Q&A after the KubeDNA talk.

My take: Hetzner plus Ansible plus Kubernetes is a combination I know well, and it really is cheap to run once it’s automated. The harder part is the one on his dependencies slide. The component catalogue is easy to build. The tested compatibility matrix behind it is the actual product. Using Kyverno for compliance controls is a sensible choice for a small team, because the policies are plain Kubernetes resources.

JetBrains closes the evening

JetBrains closed the evening with a slide about GoLand as “the IDE that supports your DevOps workflow”, along with a voucher code for attendees. The JetBrains host said the GoLand team is one of the most responsive teams in the company: send them a feature request and they’ll often follow up with an interview. He also handed a speaker a gift made by one of the engineers on his team.

At the JetBrains wall before the November meetup.

Related

• Platform Engineering Amsterdam Meetup, February 2025
• Platform Engineering MeetUp Amsterdam: Human Intelligence
• Platform Engineering Maturity Model
• Platform Engineering Team Topologies That Actually Ship