Sans Big Tech Part 2: The personal cloud

In Part 1 of this series, I explained why I have embarked on a long journey towards digital independence from Big Tech and Big Risk. This post documents the first step of that journey where I start building a personal cloud.

When Big Tech provides free services, these are not really free. First, we pay for them with our privacy. Second, the free service can at any time morph into a freemium service, and once we have been locked into the service, we might have no choice but to pay up. Third, if the service is discontinued at any point, the cost of migrating to an alternative can be very high. In extreme cases, there could be loss of access to invaluable data. As a finance professor, I always tell my class that there is no free lunch. If we do not want to pay the invisible costs of the Big Tech’s “free” services, we will have to pay a visible cost. This visible cost of creating the personal cloud has many components:

  1. We need our own server where we will run our cloud applications. There are two options: buy or rent. For most personal servers, we can get by with quite low end machines. I run a server at home on a $35 Raspberry Pi, and while we might want a more powerful server to run all my cloud services, the cost would be well below $500. The server does not need a display, keyboard or other peripheral, and we will run Linux on it to avoid paying for Windows. The main issue with running our own server is that of ensuring a high level of uptime and reliability. Even if we assume that the power supply and the network connection are highly reliable, we should still worry about some hardware or software failure that happens when the whole family is on a two week trip away from home. With nobody at home, there is no way we can get the server back up. Even a hard reboot of the machine might sometimes need physical access to the machine; and if some part has to be replaced, it obviously cannot be done remotely.

    The advantage of renting a Virtual Private Server (VPS) in the cloud is that hardware maintenance is not our problem anymore. If the server crashes, the VPS provider would move our virtual machine to a different physical machine. Soft and hard reboots can be done remotely. Instead of the upfront cost of the machine, we now have a monthly charge (less than $10 a month) for renting the server. All things considered, this probably work out cheaper than buying our own server. The big disadvantage is that of dependence on the VPS provider, and I will come back to this issue later.

  2. If we decide to run our own server, we also need to get a static internet (IP) address so that we (or anybody else) can access our cloud server from anywhere. The Internet Service Providers (ISPs) who give us a broadband connection at home usually give us a dynamic IP address that is perfectly fine for accessing the outside world from home, but is quite useless for accessing something at home from outside. Most ISPs would give us a static IP address if we ask for it, but there may be a charge for this. If we are renting a server in the cloud, we do not have to worry about this as most of these providers also bundle a static IP address with the server.

  3. If we are going to run a website or an email server, we need to pay for a domain registration that gives us our very own human friendly address in the online universe. For services that we are running for ourselves (a cloud backup service for example), this is not critical, and we can get by with just the numerical IP address. In case of a web or email server, other people need to find us, and then we need a domain name. Commodity domain names come quite cheap: $15-20 a year.

For the reasons already mentioned, I chose to put my server in the cloud, and that brings up the issue of dependence on the VPS provider. Since the whole purpose of the exercise was to de-risk the dependence on Big Tech, have I accomplished anything? The answer is that VPS is a commodity service that can be easily replicated by plenty of other VPS providers who operate in a very competitive market. If the current VPS provider shuts down, I will just switch to another provider and transfer my data and software there. Actually, I plan to retain very minimal data on the server, and the bulk of the work will be that of installing and configuring all the software. There is no lock-in with the current provider because I use only open source software, and access the server using only open protocols (like ssh or http). Big Tech by contrast is an oligopoly, and most of their services cannot be replicated by other providers.

As a further precaution, I consciously avoided the big cloud services like Amazon, Google and Microsoft, and chose one of the cheaper and smaller VPS providers. I looked at the popular VPS providers that offer something in the $5-10 range and read some reviews, but my final choice was based on a word of mouth recommendation. I have been using this VPS for more than a year now, and during this period, I have experienced two episodes of downtime. One was when a major software upgrade by the VPS provider went wrong and most of their customers lost connectivity. The VPS provider had to roll back the upgrade to restore the service, and there was a downtime of several hours. Another was a problem specific to my server where they had to move me to a different hypervisor and then I had to reboot my server to restore connectivity. The giant cloud providers would probably have much lower downtime, but they would also be twice as expensive. Moreover, my “Head in the cloud, feet on the ground” strategy makes me less vulnerable to downtime.

The costs of the VPS and the domain name are the only monetary cost involved in my journey towards digital independence from Big Tech and Big Risk. Everything else in the journey will only involve expenditure of time and effort to install and configure different cloud services on my personal piece of the cloud. All the software will be open source and will cost nothing.


4 thoughts on “Sans Big Tech Part 2: The personal cloud”

  1. […] A year ago, I discovered EteSync which encrypts the calendar before uploading to the server. Only the local clients see the plain text calendar as they decrypt what they get from the server and encrypt what they send to the server. Since the server is just a storage facility, it does not need to know the encryption password. The server uses a separate user authentication password to provide read-write access to the encrypted file. EteSync offers a subscription service in which they host the encrypted calendar on their server. But it is an open source software and it also offers a self hosted solution. The EteSync mobile phone clients work equally well with the self hosted server. And by then, I had already setup my personal cloud. […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s