On Tuesday 11 March 2025 I went to a Data Union Amsterdam evening called âMLOps in Practice: A Balancing Act Between Cool Tech and User Needsâ. It was a panel, not a series of talks: four practitioners from four very different Dutch companies on high stools behind one table, with a moderator and slides shared from their own platforms. That format suits MLOps well. Comparing how four organisations split responsibilities is more useful than one polished vendor story.
The title slide listed the moderator and the four guest speakers.
The panel
The title slide and the calendar invite listed the line-up:
- Folkert Stijnman (moderator), Freelance AI & ML Engineer and Instructor
- Asia Krajewska, Tech Lead MLOps at Adyen
- Jelmer Borst, Domain Lead Analytics & ML at Picnic
- Maria Vechtomova, Manager ML Engineering & MLOps Tech Lead at Ahold Delhaize
- Sander van Dorsten, Senior MLOps Engineer at Royal Schiphol Group
Early on, the organisers ran a live poll asking âWhat do you hope to gain or learn from this panel session?â The word cloud was a fair snapshot of the room: How other companies do MLOps, MLOps best practices, New best practices, Insights, Networking, Organisational setups, User Adoption, MLflow, MLOps culture, Ways of working, Some lessons learned, pitfalls, What is MLOps, and, honestly, Food. One answer stood out to me: âWhether to switch my job to MLOps engineerâ.
My seat for the evening, a few tables back from the panel.
Schiphol: âWe are Hermesâ
The part of the evening I photographed most was Schipholâs. The slide was titled âWe are Hermesâ, with the subtitle âCentralized MLOps Teamâ and the mission line â[a u]niform way to develop and deploy Machine Learning productsâ. It introduced two people: Sander van Dorsten (Senior MLOps Engineer) and Kiki van Rongen (MLOps Engineer).
âWe are Hermesâ: Schipholâs centralised MLOps team.
Next came an hourglass diagram, the clearest picture of the teamâs leverage I saw all evening:
- Upstream: 900 IT professionals and 180 data professionals
- MLOps team: the two people from the previous slide
- Target audience: 20 data scientists and 10 machine learning engineers
A follow-up slide broke the audience down by role: MLOps engineers at the top, then machine learning engineers (10 FTE), data scientists (20 FTE), and a row for data analysts, UX and other roles.
Two MLOps engineers in the middle, serving around 30 ML practitioners.
The Schiphol AI Techstack
Later, the âSchiphol AI Techstackâ slide split the platform into six boxes. These are the names and logos I could read in my photos:
- Development: Databricks, Jupyter, GitHub and one more tool
- Data / ML Platform: Databricks, MLflow, Unity Catalog, Airflow and Kubernetes
- Monitoring: OpenTelemetry and Slack, plus two other tools
- Deployment: Argo, GitHub and Helm
- LLM Platform: Azure, OpenAI, FastAPI and LangChain
- Serving: Kubernetes, Databricks, Streamlit and FastAPI
Six boxes, with a separate LLM platform alongside the classic ML platform.
My take: what I like here is that the LLM platform is its own box, but it reuses the same building blocks (FastAPI, Kubernetes) as classic serving. For a team of two, sharing serving and deployment patterns across ML and LLM workloads is the only way to stay sane.
Adyen and Picnic: the same problem, different shapes
Adyen and Picnic shared slides too. Adyen showed an organisation map: an MLOps team in the middle, linked to several ML teams, next to a Feature Platform, an Experimentation Platform and Data Platform Development. A second Adyen slide traced the model lifecycle: Getting Data â ML experiment & iterate â Train for production â Deploy & Serve â A/B Testing. Jupyter, Airflow, the Feature Platform, Backoffice and the Experimentation Platform sat above it. Inside a âMachine Learning Platformâ area, marked as the MLOps teamâs scope, were components such as ArgoYEET, MLFlow and a real-time Serving layer.
Adyen: one MLOps team serving many ML teams, and the lifecycle its platform covers.
Picnicâs slide was titled âThe blueprint for our platformâ. Its boxes were Feature Store, Experimentation Environment, Code Repository, Deployment Environment, Model Registry and Monitoring. Logos I could make out included Snowflake, Jupyter, MLflow, GitHub, Argo, FastAPI, Kubernetes, dbt, PagerDuty and Slack.
Picnicâs blueprint: a feature store and model registry framing the experiment-to-deploy path.
What I took home
- The org chart comes first. Schipholâs hourglass and Adyenâs team map were both about who the MLOps team serves before what it runs. That matches the roomâs own poll, where âOrganisational setupsâ and âWays of workingâ sat next to the tooling questions.
- The stacks converge. Three companies and three slides, yet MLflow, Argo, Kubernetes, FastAPI and Jupyter kept coming back. The differences were in the data layer (Databricks and Unity Catalog versus Snowflake) and in how much each team builds itself.
- Small central teams need paved roads. Two MLOps engineers for around 30 ML practitioners only works if there is one uniform way to develop and deploy, which is exactly what the Hermes slide promised. This is the same platform-engineering logic I apply to Kubernetes platforms.
Thanks to Data Union Amsterdam and the panellists for an evening of real platform diagrams rather than marketing slides.
