A Tale of Two Fludes: The Architectural Split of Enterprise and SaaS Models
· 3 min read
Extracting specific code into an independent private submodule, as described in the previous article, allowed us to stabilize the engine’s core. The legal boundaries were drawn, and the base architecture—a smart parser and two-level caching—proved its effectiveness.
The next logical step was transitioning from an internal tool to a commercial product. However, at this stage, we faced a fundamental contradiction between the corporate operational model and the demands of the mass market.
The Illusion of Universal Distribution
Initially, Flude’s architecture was shaped by the needs of a large corporation. Security requirements in such environments are categorical: the tool must function within a closed perimeter, guaranteeing that the source code never leaves the company’s servers.
To solve this, we integrated directly. A package with scripts was handed over to the client and run locally in their CI pipeline, reading configuration files directly from the repository. Within a corporate environment, this delivery model (whether source or bytecode) is ideal: the closed perimeter and strict legal obligations reliably guarantee the safety of intellectual property.
However, when planning to scale to the public market, it became obvious that directly copying the Enterprise distribution approach was technically and conceptually inapplicable.
Losing Control over Distribution
The closed-contract model works perfectly in the Enterprise sector, but to ensure stable product growth, we needed to enter the mass B2B/B2C market: small teams and independent developers.
The obvious problem was that handing over source Python scripts or a ready-made Docker image to users outside of corporate agreements inevitably leads to losing control over product distribution. Without strict legal barriers, open distribution technically allows bypassing licensing mechanisms and uncontrollably replicating the system’s core.
Consequently, the approach that is standard for a trusted corporate environment turned out to be structurally incompatible with a public business model.
The Divergence
To protect the product’s core, we had to rethink the delivery paradigm itself. Flude’s architecture was physically divided into two independent models:
- Enterprise Flude: An autonomous, local solution. Delivered exclusively under targeted contracts. Functions offline, processes code locally, and integrates with the configuration directly in the client’s repository.
- SaaS Flude (Public Market): A cloud-oriented model. The parser’s core is never handed over to end users. Instead, a “thin client” (lightweight CI scripts) is provided, whose sole task is packing source files and securely transmitting them via API. All computational load and parsing logic remain encapsulated on our servers.
Moving to the Cloud and the Unexpected Benefit of Binaries
By adopting the SaaS model, we secured our algorithms, but significantly complicated the technical implementation. We had to design a distributed system from scratch capable of receiving and processing third-party code.
Interestingly, it was at this stage that the concept of a “single binary”, which we had rejected for public distribution, turned out to be our own salvation. To avoid managing complex Python environments and dependencies on every cloud worker, we compiled our core. A standalone binary became the perfect solution for quick startups inside our own SaaS infrastructure (and later, a convenient delivery format for Enterprise clients).
How we designed the cloud with the Zero-Trust concept in mind, and why configuration files that worked flawlessly locally turned into a critical attack vector (RCE) in SaaS, we’ll tell you in the next episode.