Cloud, managed or onsite: choosing where your data platform runs

Where a piece of infrastructure runs is a business decision dressed up as a technical one. It decides who is on call, whose invoice the computing appears on, which auditor's questions you can answer, and how hard it is to leave. redfly can be deployed in three shapes, and the choice between them is usually made by the operations leader or the chief technology officer rather than by the engineers who will use it day to day. This article sets out the three shapes, who each one suits, and why we built the product so that the decision can change later.

The three shapes

The first shape, and the one we prefer, is the customer's own cloud account. The redfly API (the single entry point an application calls for its data) and the Sync Service (the process that keeps the memory cache in step with the database) run inside the customer's own account with their cloud provider, next to the database they already pay for. redfly is licensed; the hosting is the customer's.

The second is fully managed. redfly runs in our cloud as a service we operate, connected to the customer's database.

The third is onsite (on the company's own servers). The same software runs on servers in the customer's own data centre or server room, behind their firewall, against a database that never leaves the building. In all three shapes the application code is the same, and the customer's codebase contains no cache logic.

Your own cloud account: the default for most

We prefer this shape for a plain reason: it keeps the money and the control where they belong. There is no hosting markup in our price because we are not hosting anything. The customer keeps whatever discounts they have already negotiated with their cloud provider, and the computing and storage appear on the bill they already reconcile every month.

It also keeps the data inside a boundary the customer already governs. Access policies, network rules, backup schedules and audit logging are the ones the security team already signed off. redfly is another workload inside that boundary, not a new destination for the data. During the architecture review we size the footprint (the servers and memory the deployment needs), and the savings we quote are net of that footprint.

This shape suits any company that already runs a cloud account with someone responsible for it. That includes most software companies past their first few hires, and most mid-sized businesses that have moved a production database to the cloud.

Fully managed: for teams without operations staff

Some companies have a product, customers and revenue, and nobody whose job is to keep servers healthy. Asking that team to run another service in their account is asking them to do work they did not hire for. For them, fully managed is the right shape.

In this arrangement we set up, monitor, upgrade and tune the deployment, and the customer's team sees only the API. The trade is straightforward. The customer gives up some control over where the service physically runs, and in return the operational burden is ours.

Fully managed is not the premium option; it is the option for teams who would rather ship features than run infrastructure.

Onsite: for existing data centres and regulated work

Plenty of businesses own servers and intend to keep them. Manufacturers, logistics operators and long-established firms often run a data centre they have already paid for, staffed by people who know it. Others are in regulated industries where the rules, or the auditors interpreting them, require that certain data never leaves premises the company controls.

For both, onsite is the natural fit. redfly runs on the customer's hardware, against the customer's database, on the customer's network. Nothing about the product assumes a cloud. The memory cache, the sync process and the API all run as ordinary software on ordinary servers, so the operations team treats the deployment the way it treats any other internal system.

The cost picture differs from the cloud, but the mechanism is the same. Fewer reads reach the database, so the database server has more headroom, and the next hardware upgrade can often wait.

Why the choice can change

The reason all three shapes are possible is a design constraint we hold to: redfly has no dependency on any cloud vendor's proprietary services. It uses databases the customer already runs (SQL Server first, then MongoDB, then Postgres), a memory cache (Redis) that is available everywhere, and software written to run wherever those two things are.

That constraint has a consequence for the business. A company that starts fully managed because it has no operations staff can move into its own cloud account once it hires them. A company that starts onsite can move to the cloud when the data centre lease ends. A company that moves clouds for commercial reasons takes redfly with it. None of these moves needs the application rewritten, because nothing in it is tied to a particular vendor's services; the work is in the deployment, not the code.

Which cloud

Azure is our preferred cloud. SQL Server on Azure with C# goes live right away, and everything else follows a clear order of preference during onboarding. Other clouds work; they come later in that order rather than being excluded. The preference is about how quickly we can get a customer live, not about what the product can do.

redfly fits companies that want the database to cost less and hold up better under load, without handing the decision about where their data lives to the vendor supplying the fix.