Skip to main content

2 posts tagged with "case-study"

View All Tags

Replacing a Custom Feature Flag Platform at Solaris: GitOps, Data Residency and OpenFeature

· 10 min read
Olivier Laviale
Olivier Laviale
Principal Engineer at Solaris SE

Replacing a Custom Feature Flag Platform at Solaris: GitOps, Data Residency and OpenFeature

A note from GO Feature Flag

We are happy to welcome Olivier Laviale as a guest contributor to the GO Feature Flag blog.

Olivier led the initiative to replace the in-house feature flag platform at Solaris SE, a German Banking-as-a-Service provider. Below, he walks through the constraints that shaped the search, the seven tools he weighed, and why the team landed on GO Feature Flag — including the rough edges he hit and fixed on the way in.

Separating deployment from release is basic hygiene for a modern engineering organisation. For a Banking-as-a-Service provider, it stops being hygiene and becomes a requirement: when a new feature does not behave the way it was supposed to, we need to switch it off immediately, not schedule a rollback.

Our in-house feature flag solution served us well for a long time. It was straightforward, it did what it was built to do, and for basic on/off features it was entirely adequate. What it was not was something that could grow with us. This is the story of how we chose its replacement.

A quick primer, for anyone who needs it​

If you already live in flag tooling, skip ahead.

Before feature flags, a bad bug meant rolling back the entire deployment. On a large monolith, that is not a button you press — it is a process, and it can take hours while the problem stays live in production.

A feature flag turns that into a switch. You toggle functionality in production, instantly, with no redeployment. That is the whole idea, and everything else is refinement on top of it.

DataGalaxy Feature Flag Journey: How OpenFeature and GO Feature Flag Rebuilt Trust Between Teams

· 16 min read
Tom Flenner
Tom Flenner
Staff Engineer at DataGalaxy

DataGalaxy Feature Flag Journey: How OpenFeature and GO Feature Flag Rebuilt Trust Between Teams

A note from GO Feature Flag

We are delighted to welcome Tom Flenner, Staff Engineer at DataGalaxy, as a guest contributor to the GO Feature Flag blog.

Drawing on his firsthand experience, Tom shares why DataGalaxy adopted GO Feature Flag, how the team integrated it across the company, and what they learned along the way.

A few years ago, a fairly ordinary question would derail a fairly ordinary meeting at DataGalaxy: "is this feature actually live for this customer?"
Nobody in the room could answer it with confidence. The backend engineer would check a database table. The frontend engineer would check a build-time environment variable that may or may not have shipped in the last release. Someone from infra would mention an ingress rule nobody had touched in months. Three answers, three systems, and no way to know which one was telling the truth.

That meeting, repeated in different forms often enough to become a running joke, is really where this story starts. This is the story of how we went from that mess to a single, open, standardized way of answering that question, using OpenFeature as the contract and GO Feature Flag as the engine underneath it. It's also the first in a series of articles we plan to write about what feature flags have changed for us, and about the parts of this journey we haven't figured out yet.

A quick word on what a feature flag actually is​

If you're already deep in flag tooling, feel free to skip ahead. But it's worth grounding this story in the idea itself, because the term gets used loosely.

A feature flag (also called a feature toggle) is a mechanism that lets you change your software's behavior without changing and redeploying its code. Martin Fowler's Feature Toggles article remains the best reference on the topic: it separates flags into categories (release toggles, experiment toggles, ops toggles, permission toggles) and makes an argument we'd underlined long before we could articulate it ourselves: a flag isn't just an if statement, it's a piece of infrastructure with its own lifecycle, and treating it otherwise is how you end up with the mess described above.

That framing matters, because for a long time, we weren't running "feature flags" in that sense. We were running scattered conditionals with delusions of grandeur.