On-premises, cloud, or hybrid? Where to build the next project
Series II: From infrastructure to agentic projects in production. Episode 01 of 20.
A B2B portal for requests and documents may look like a single application. In practice, the interface, database, files, backups, and any AI service can have different requirements. For a small or medium-sized business, the useful question is not “Should we move everything to the cloud?” It is where each component runs, who operates it, and what happens when a connection fails. The 90-day adoption plan helps select the process; here we decide where to build it.
Three terms, one component-by-component decision
On-premises means infrastructure located in the organization's premises and administered by it: servers, storage, networking, power, and backups. Public cloud means resources supplied on demand by a provider, with elastic allocation and measured usage. A rented virtual machine alone does not provide all the advantages of managed services, and a cluster of company-owned servers does not automatically become a “private cloud.” Under NIST's definition, a private cloud is cloud infrastructure used exclusively by one organization and can also be hosted off premises.
In project discussions, a hybrid architecture distributes components between company infrastructure and cloud services. NIST's stricter term “hybrid cloud,” however, requires two or more distinct cloud infrastructures connected to enable data and application portability. The distinction matters when comparing offerings: the label alone does not describe migration capabilities. No option automatically guarantees security, control, or low costs.
Five questions before choosing
Criterion | Question to verify | What could change the placement |
|---|---|---|
Data and access | Where are the documents, who may process them, and what data leaves the environment? | Keeping data on premises may require a secure connection to an application in the cloud. |
Latency and connectivity | How long do real operations take between the application and database, including over a degraded connection? | Components that exchange data frequently may need to run close to each other. |
Availability | What happens if the premises, the provider, or the link between them fails? | Backups and recovery mechanisms must address the relevant failure. |
Operations | Who applies updates, monitors incidents, and can respond outside business hours? | Managed services reduce some work, but do not remove the company's responsibility. |
Full cost | What do we pay for equipment, power, staff, usage, transfer, recovery, and exit? | The better option may change with volume, traffic fluctuations, and project duration. |
This matrix is a discussion tool, not a universal score. For each criterion, record a measurable requirement, the available evidence, and the person who approves the trade-offs. If traffic or requirements are unknown, start with measurements from a pilot, rather than an architecture drawn only around a provider preference.
Inventory the flows before requesting quotes: who uploads files, where they are processed, which systems the portal consults, and how often data crosses the boundary between environments. Draw authentication and administrative flows separately. A system may keep files on premises yet send names, addresses, text excerpts, or telemetry to other services. Check these paths with the team responsible for the data and with providers, then limit access to what each function needs.
Hypothetical example: the partner portal
Suppose the company receives requests and documents from distributors, and an operator reviews each response. An AI agent integrated into the portal could classify requests or propose a summary, without approving documents on its own. AI agents used by the development team to write and test code are a separate category; where their tools run does not automatically determine where partners' documents go.
One option to evaluate, rather than a validated recommendation, places the interface and API, the interface through which systems exchange requests, in a managed cloud service. The database and documents initially stay in company infrastructure, with access through a controlled connection. The external AI service receives only permitted, minimized excerpts. If that condition cannot be met, test local inference, meaning running the model on company equipment, or defer the feature. Logs, identity data, metadata, and backups must be inventoried separately: “the documents are local” does not tell us where all the project's data goes.
This arrangement may perform poorly if every page view crosses the link to the database. A practical trial measures complete operations under realistic traffic, including document uploads and searches. Test a connection outage: does the portal show a clear error, queue the request, or stop uploads? The choice depends on the business requirement and test results. One alternative is to move the API and data together into a suitable environment with the necessary controls; another is to host the entire portal locally. Neither should be adopted just because it looks simpler on a diagram.
Responsibility does not leave with the server
In the cloud, the provider is responsible for certain infrastructure layers, while the company remains responsible for configuration, identities, the application, and data, according to the service selected. For a virtual machine managed by the company, operating-system updates may still be its responsibility; a managed service shifts more operational work to the provider. The contract and actual architecture determine the details. On premises, the company must also cover equipment, power, connectivity, replacement of components, and incident recovery.
In every setup, decide who may read the documents, where encryption keys reside, what is retained in logs, and how restoration is tested. A private connection does not replace access controls. If you use an external AI model, explicitly check the path of requests, retention, and the provider's terms before sending real content. Do not infer the residency of all data from the region selected for the database.
Costs and the decision record
Compare two or three scenarios over the same period and against the same availability requirements. For on-premises infrastructure, include equipment purchase and replacement, space, power, cooling, licences, staff, maintenance, and backups. For cloud, include resources, managed services, storage, traffic between environments and to external destinations, monitoring, and support. In both cases, add migration, recovery, testing, exit from the solution, and AI usage. Do not turn an advertised hourly price into a “total cost” without traffic volumes and transfer rules. Case studies on sizing may illustrate methods, not identify a winner for every company.
The outcome of this episode is a decision record with one row each for the interface/API, data, documents, AI, logs, and backups: proposed location, reason, owner, network dependency, estimated cost, and an alternative for an outage or migration. Mark assumptions and what the pilot must measure. Revisit the record if volume grows, connectivity becomes a constraint, or the team can no longer sustain operations. In the next episode we will choose how to run the system, from virtual machines to containers and, only if justified, Kubernetes.
Sources
- NIST SP 800-145, The NIST Definition of Cloud Computing (2011), for the definitions of private and hybrid cloud.
- Microsoft Learn, Azure hybrid options, “Hybrid considerations” section, for placement, latency, data, and operations.
- AWS, Shared Responsibility Model, for the division of responsibilities by service.
- Rosati et al., Right Scaling for Right Pricing: A Case Study on Total Cost of Ownership Measurement for Cloud Migration (2019), a case study rather than a universal price comparison.
Next step
Choosing infrastructure for a real project? Talk with the i8 team about a decision record and a measurable pilot.
