Platform Engineering Vienna

Welcome back to our Meetup event in August. As usual we are looking forward to great talks, discussions and beers.
Big thanks to Willhaben for hosting!

Agenda:

• Doors open 5:30 p.m.
• Introduction - 6:00 to 6:15 p.m.
• Talk 1 - 6:15 to 6:45 p.m.
• Speaker: Lukas Zainzinger
• Title: Iterative Platform Engineering: Lessons from willhaben’s AWS Migration
• Abstract: Platform engineering isn't built in a day—especially when you are managing the needs of multiple engineering tribes. In this talk, we will explore willhaben’s ongoing journey into platform engineering. Following our full migration to AWS, we faced unique challenges that highlighted the need for a better developer experience. I will share how we are currently tackling these issues through small, iterative changes. Join me for an honest look at what worked, the hurdles we are still overcoming, and a sneak peek into our platform roadmap for the years ahead.
• Break - 6:45 to 7:00 p.m.
• Talk 2 - 7:00 to 7:45 p.m.
• Speaker: Martin Lorenz
• Title: Your Domain Model Is Your Platform: From Events to a Running Internal Developer Platform
• Abstract: Platform engineering is about reducing cognitive load. Giving product teams golden paths that let them ship business value without fighting infrastructure. Most internal developer platforms deliver this by stacking abstractions on top of existing complexity: service catalogs, deployment pipelines, self-service portals. The infrastructure is still there, and someone still has to build and maintain it. This talk argues for a different starting point: instead of abstracting infrastructure, eliminate the need to write it. An event-driven domain model (the commands users issue, the events that result, and the views stakeholders need) already contains everything required to derive the infrastructure. Using the open-source Reventless framework, we show how typed domain slices become the single source of truth, and how database schemas, event routing, GraphQL APIs, a generated UI, and complete Pulumi Infrastructure-as-Code all fall out of that model. So the platform and the running system stay in sync by construction, not by discipline.
  The heart of the talk is what this does to team autonomy and to the platform team's own role. Because each slice owns its commands, events, and read models as a self-contained unit, product teams add features by adding slices. No coordination with other teams, no changes to existing code, no infrastructure tickets. The platform enforces contracts through a strict type system: an inconsistent slice fails to compile. That shifts the platform team from gatekeeping to enabling: contracts are held by the compiler, not by review queues. The same typed model is also an ideal AI target: an LLM drafts a slice, and the compiler validates it the moment it lands. The team doesn't go away. The repetitive infrastructure work does. What's left is the work only they can do: keeping the domain model coherent across teams, running the live system, and setting company-wide rules. We put the whole claim on stage with a live demo of a deployed simple online shop, seen two ways: a Domain Map (the model the teams write) and a Resource Map (the live AWS resources that model became). By the end, "the domain model is the platform" is not a slogan but something you have seen for yourself - the same system, from both sides.
• Networking - start 7:45 p.m.