Hosting - Part 1 : From the garage to the cloud

When designing a digital product, a lot of focus is placed on marketing and UX, and the choice of hosting is often quickly overlooked. Ultimately, this becomes a non-choice for the customer, who is imposed with a hosting provider by the provider who will develop the solution, or worse, a non-choice for the development team that is imposed with this choice by a customer without understanding the impact it will have on the product or the development cost. We will try to shed some light on this with this series of articles by going into more and more detail.

I propose to retrace here the different steps that led us to the Cloud and its solutions to understand the current state of the art. If this is something you already master, feel free to go directly to the following parts: Hosting 2: The different levels, Hosting 3: What the cloud does for us and Hosting 4: The cloud, more expensive really?

To illustrate my points, let's take the example of a digital product based on a mobile application that will offer various services using a centralized server. For example, the "Where are the toilets" application that allows you to find the nearest public toilets to your location, but also to rate them, etc.

But what is a server?

Before starting, we need to clarify what "server" means. In everyday life, we know what a "Server" is. It's the person who brings you the dishes when you're in a restaurant. Let's look at the interactions you have with him.

→ The Server walks between tables waiting for a customer to call him

← You are at your table, you give him a sign

→ He comes to you and asks how he can help you

← You formulate a request, for example: "Could I have a jug of water please"

→ He goes to get the jug, brings it back to you and asks if he can do anything else for you.

← As you are polite you tell him it's perfect and release him to go see another customer.

In the context of a mobile application, it's a bit the same thing except that the Client is the mobile application, the words or signs are network communications and the jug of water is usually data.

→ The server waits for new connections

← The application initiates a connection with the server

→ The server accepts and listens to the request

← The application requests the list of toilets

→ The server retrieves this list from its database and returns it

← The application retrieves the response and then closes the connection

Here I am talking about the server in the sense of the application server. It is different from the "server", the machine that will host the application server software. In the past, hosting a server meant having a physical machine in your garage or office, taking care of its maintenance, security, and power supply. However, as technology advanced, it became possible to host servers remotely, in data centers. This is known as "cloud hosting".

The main advantage of cloud hosting is that it allows for scalability, meaning that you can easily add or remove resources depending on the needs of your application. It also provides a high level of reliability, as the data centers have redundant systems in place to ensure that your application is always available. Additionally, cloud hosting providers take care of the maintenance and security of the servers, allowing you to focus on developing your application.

As the use of cloud hosting has become more prevalent, a variety of cloud hosting solutions have emerged, each with its own advantages and disadvantages. In the next parts of this series, we will explore these solutions in more detail and discuss how to choose the right one for your product.

Where to put this server?

The Garage

All the big ones, Google, Microsoft, Apple, Hp, etc., started in the same place to put their first server... Their garage!!! Okay, the newer ones like Facebook and company went straight to the next step.

At first it was enough, you had to buy a slightly powerful machine, take out a subscription with an internet provider like Wanadoo 👴 And off we go. ✌️

The problem with this first version is that if there are works in my street and they cut the power, or if SFR or Orange comes to fiber my neighbor and disconnects me in the process 🤬, my server is no longer accessible! We'll go put it somewhere else for more safety.

Host version 1

Rather than buying a new machine, the host offers to rent one to me. So I'm going to let them completely manage my hardware. For that I have to go through a form, pay, once the payment is validated, the provider checks if they have it in stock or will order it and then put it in place. In short, 2 weeks later I receive an email with the connection information and I can finally start installing it. It's been long, but here it is, my backend is deployed on it. 🤟

As I rent this machine quite expensively, I'm also going to put the backend of another application I'm developing on it.

I'm not a fan of this approach because if there's a flaw on the backend of "Where are the toilets" and a hacker hacks my server through this backend, it also compromises my other application. Plus, I'm starting to have a lot of people on this application and it impacts the response time of my other applications. We should be able to do better!

The host version 3

The provider is offering me another solution, rather than renting a physical machine like I could have at home, they are proposing for me to rent a virtual machine. Basically, a computer within a computer. For this I can take a small one for my other application and a bigger one for my first backend. My backends are isolated so there is no risk of compromise between them. Plus, since it's virtual and they run on a lot of machines managed by the provider, I have my machine right away. Too happy 😍

I did a bit of advertising for my application and I am starting to have quite a few users with their data, if there is an earthquake or fire in the Data Center of my host, I lose everything. I have to backup all my data elsewhere regularly and in addition, if it happens, deploying my backends on a new server will take me some time, maybe several days. How to make sure that it doesn't happen? Plus, every month I have to go back to all my virtual machines to update the security patches of the operating systems.

It takes me a lot of time and I have to develop tools for that. I really have better things to do 😞

The cloud ☁️

In this case, I looked at the "Cloud" it seems good but to really benefit from its advantages I had to review a bit the code of my backend to be able to use the services they offer. Otherwise, it wouldn't bring much more than my old host. So I modified my backend to use the database and storage system of the "Cloud Provider". But at least now I am relaxed, I can sleep with both eyes closed. The provider manages for me the backup, security patches and availability of the different services. In case the server would no longer respond, I was able to use their automatic monitoring system to ensure that a new server is automatically deployed. Plus, I was able to do all this with the "Terraform" tool that uses the Cloud Provider's APIs to configure all this for me. So I can focus on adding features for my application and not on tools that don't add value to my users. 🙌

Conclusion.

Hosting a backend is not so simple. If we want to do it by ensuring that it is always available, it requires taking into account several aspects such as backups, recovery time, security etc. The more we go towards advanced hosts, the less we will have to take care of and the more we will be able to focus on bringing value to the digital product we are developing.

Now that we have seen the different problems that have led us to the Cloud, I suggest you to go back quickly on the different acronyms by looking at this article Hosting - Part 2 : The Differents Levels or to see, on a concrete architecture, what AWS does for us in this article Hosting 3: What the cloud does for us.