Hosted Data Architecture

Every company collects data: customer addresses, orders, measurements, texts. This data has to be stored somewhere, namely on computers that run around the clock. Such continuous runners are called servers. In a hosted data architecture, these servers don’t sit in the company’s own basement, but in a provider’s data centers. The company therefore rents storage space and computing power instead of buying it. Access happens over the internet, usually via a fixed technical interface. The counterpart is called on-premises: here the company operates all the equipment itself and is also responsible for it itself.

Why companies are moving their data out of their own basement

Owning servers is expensive before they even accomplish anything. You buy hardware, air-condition a room, and hire specialists. And you already have to guess today how much storage you’ll need in three years. Guess too low, and you grind to a halt. Guess too high, and expensive equipment sits gathering dust unused.

Rented storage solves this guessing game. If demand grows, you book more capacity, often within minutes. If it shrinks again, you pay less. An online shop can thus absorb the rush before Christmas without paying for that peak load all year round. Experts call this flexibility scalability.

For AI projects, this point is especially important. Training large models requires enormous amounts of data and specialized graphics processors. Hardly any mid-sized company buys itself an entire hall full of technology for this purpose. It rents the capacity for a few weeks and gives it back afterward.

What happens between the user and the data center

Technically, there is always an interface between the user and the data, usually called an API. An app sends a request to this interface, for example: give me yesterday’s orders. The provider looks up the data on its machines and sends the result back. The user notices nothing of the servers themselves.

So that nothing gets lost, the data is almost never stored just once. The provider creates multiple copies, often in different buildings or even countries. If one location fails, another takes over. This duplication is called redundancy and is the main reason why large providers rarely fail completely.

Security, however, is a matter of negotiation, not an automatic given. The data is encrypted during transmission and storage, meaning it’s put into an unreadable form. But who holds the matching key is a decisive question. If the provider holds it, it can technically read along. A common misconception is that rented storage is inherently less secure than owning it. Often the opposite is true, because large providers employ entire security departments.

From Google Drive to the debate over storage location

In everyday life, almost everyone uses such architectures without knowing the term. Photos in Google Photos, files in iCloud, chats in a messenger: all of this sits on someone else’s servers. School platforms and class chats work the same way. One’s own laptop is merely the window onto the data.

In business news, the term usually comes up in connection with three major providers: Amazon Web Services, Microsoft Azure, and Google Cloud. Between them, they largely divide up the market. Accordingly, the issue of dependency comes up often. Whoever has all their data with one provider can only get away again with great effort. This problem is called vendor lock-in.

A second recurring topic is the location of storage. The EU’s General Data Protection Regulation sets strict rules when personal data leaves the Union. That’s why providers now explicitly advertise data centers in Germany or France. Projects for a European cloud infrastructure pursue the same goal: keeping control over one’s own data.