Cloud vs. On-Premises — Shared Hosting and Scope of Responsibility

This article covers the three arrangements for where an app runs: on-premises, shared hosting, and cloud.

The difference comes down to one point: who owns the server hardware, and who decides what goes inside it.

At the end, it also covers where the major cloud providers — AWS, Google Cloud, and Azure — fit.

On-premises is the only one where you own the hardware.

The three arrangements differ in who owns the server hardware and who decides the setup

The three differ on two points: where the server hardware sits, and who decides the setup — the OS (the base software that sits between the hardware and your programs and handles files, networking, and the screen) and the runtime.

The provider's building where the hardware sits is a data center, a dedicated building that houses and runs a large number of servers.

A partition inside one of those machines that runs as an independent server of its own is a virtual server (setup guides also call it an "instance").

Whether you can choose the setup yourself is what separates shared hosting from the cloud.

You can work only with your own partition; the neighboring partition and the physical server itself are not visible to you.

One sign-up lets you start as many servers as you want and stop them when you are done.

The price is set by how much you used and for how long.

Introductory books also call this arrangement, which anyone can sign up for, the public cloud.

The difference is who owns the hardware and who decides what is inside

The three differ only in whose server hardware it is and who decides what goes inside it.

On-premises is where both the hardware and what goes inside it are yours, shared hosting is where you leave both to the provider, and the cloud is where the hardware belongs to the provider and you choose the setup.

Scope of responsibility — which layers the provider manages, and where your part begins

What you look at when choosing is who fixes it when it breaks.

A server is made of five layers: the building with its power and network lines, the hardware, the OS, the runtime, and the app with its data.

How the two sides split the management of each layer is the scope of responsibility (cloud providers call it the shared responsibility model).

With on-premises all five layers are yours to manage; with shared hosting only the top one is.

With a cloud virtual server, the boundary falls between the hardware and the OS.

Ordering parts and replacing them when the hardware breaks is your job only with on-premises.

With shared hosting and the cloud the provider replaces it, and in the cloud you can simply start up again on different hardware.

Checking that the app and its data work as before, though, is on you in every arrangement.

The provider supplies only as far as the hardware; once you have chosen an OS and booted it, the rest is yours.

The provider does not fix bugs in your app or restore lost data.

Below the boundary is the provider, above it is you

A server is made of five layers, and the provider manages the lower ones while you manage the upper ones.

With on-premises all of it is yours, with shared hosting only the top layer is, and with a cloud virtual server everything above the hardware is yours — the provider fixes only what is below the boundary.

In the cloud, you choose where each part of the app goes

Virtual servers are not the only thing in the cloud.

When you choose a managed service (a service where the provider installs, updates, and troubleshoots the OS and runtime, and you only configure and use it), the boundary moves upward.

Each part goes somewhere different, so the boundary is different for each part too.

With file storage and a managed database, managing the OS and the runtime moves to the provider's side.

With a managed database, all you do is design the tables and read and write the data.

For the backend there is also a place that runs the processing only when a request arrives.

Everything inside the box is the provider's hardware, and you own none of it.

Even so, you install and update the OS and the runtime inside the virtual server yourself.

Choosing where a part goes moves the boundary with it

The more you leave to the provider when you choose where a part goes, the less work is left to you.

With a managed database all you do is design the tables and read and write the data, while for the backend on a virtual server, everything above the OS stays yours to manage.

AWS, Google Cloud, and Azure — the categories they share, and the areas each is strong in

AWS, Google Cloud, and Microsoft Azure are the names of the clouds run by Amazon, Google, and Microsoft.

Each is one company's name for its cloud, and each contains a large number of services.

The geographic unit in which data centers are grouped is a region.

Choosing a region close to the people using the app shortens the time a request and response take to make the round trip.

The category in the leftmost column tells you what a name does, even a name you are seeing for the first time.

What the three companies have in common stops at these categories.

Even when the same categories are covered, each provider has built out different areas more heavily.

You do not have to settle on one company.

Using several providers, each for a different purpose, is multi-cloud, and you can pick the provider that is strong in the area each part needs.

The consoles and the terms differ from provider to provider, though, so there is more to learn and more to manage.

While the app is small, keep it with one provider, and consider splitting it up once a need comes up.

Shared categories, different strengths

AWS, Google Cloud, and Azure are the names of the clouds from Amazon, Google, and Microsoft, and all three have the same categories of service: virtual servers, managed databases, and file storage.

Because the categories are shared, once you know one provider you can read the others by mapping their names onto the categories, but each is strong in different areas, and multi-cloud, using several providers for different purposes, is another way to choose.