I'm Building The Cloud In My Garage

Currently, I am building a home VPS ( Virtual Private Server, sometimes called a cluster ), and I want to write about what it takes to set one up and why you would want to.

This is probably the least technical blog post about the subject.

When trying to figure out where to start with this home cloud experiment, I decided to start by carefully documenting my rationale for embarking on this journey. This is the beginning of a series of blog posts that will focus on making your own cloud service at home for fun and profit.

In this blog post, I will discuss two main points. The first is that the cloud is nothing special. The second is that building your own cloud has an important constraint: between the properties of good, fast, and cheap, a project may only have two of them.

When finished, this “garage cloud” will be the equivalent of $6k/month of rented cloud infrastructure. 

Let’s get started.

There Is No Cloud

It used to be that companies would need to have their own servers to host their online presence, create business software, and serve data resources for their employees.  "The cloud" changed all that. Instead of racks of servers, which required massive cost overhead, a business could use the cloud to rent those resources.  The cloud is pretty spectacular.

The cloud allows businesses to access computing power without investing in IT infrastructure.  This is the important part: because a business is renting someone else's infrastructure, the cloud removes the barrier to accessing high-end computational power.

Take an example of a business looking to become a franchise.  In the past, that company would need 10s of thousands of dollars for specialized computers called servers.  A non-trivial amount of office square footage would need to be allocated to house these giant computers.  And that’s just the beginning.

Installing giant computers isn’t the end of the story. An IT staff would need to maintain it all, and developers would need to design and implement the original business goal. Not to mention that the payoff needs to meet the projected business needs. The risk of buying too much or too little can lead to paralysis. It takes a certain amount of savvy to be confident about turning a business into a software company—at least until the cloud.

The cloud made the costs of IT overhead trivial and diminished the risk of participating. For that reason, it had legitimate hype for many years. It's also why Jeff Bezos' AWS made him the richest man in the world. My goal is not to get rich; my goal is not to give cloud providers all my money.

Good, Fast or Cheap… Pick Two

I’d like to frame this home cloud project in the context of “fast, cheap, or good… pick two”.  The saying means

• If it’s good and cheap, it will require lots and lots of time

• If it’s fast and good, it’s going to be expensive

• If it’s cheap and fast, the quality will be poor

So why do I want to build my own? There are many reasons. For me, it's fun, cheap, private, educational, and skill-building. The cloud providers are good and fast. They are cheap compared to creating an in-office VPS, but not for businesses that grow dependent on vendor lock-in. In contrast, my garage cloud will be cheap and good because I will use best practices and take my time doing so.

Good

Good can’t go fast in the paradigm of “fast, good, cheap.. pick two.”  Building a private cloud in the garage is slow and difficult — at least implementing it with best practices.  A 5-minute haircut is fast; it’s not good.  A home cluster is "good" if it mirrors a professional business cluster.  A professional VPS is good if it:

• It scales up to meet the demand.

• It doesn't require maintenance downtime.

• It secures data from unauthorized users.

• It has a snappy performance.

The actual technique to accomplish this is for another blog post.

Fast

Even with a multitude of do-it-yourself articles, every accomplishment is hard-earned.  That is because technology is difficult, and I am not trained in the cloud, but I do spend most of my time there.

Every single thing I want to build is offered as a "service" in any of the cloud providers.  It is in these services where fast replaces cheap.  Take, for instance, AWS:

Each one of these services is designed to diminish the requirements of an IT professional for a business. However, it's also designed to promote vendor lock-in to their own services.  For example, I have never purchased a domain name without being offered to host it for $25/month by that same provider.  It costs a fraction of that $25 in operational costs.  I'll speak more on this later.

There are many articles out there on how to develop your own cloud.  Those same articles only write about their specific itch to scratch.  Because the work is complex at any skill level, googling to completion is a long process that involves bridging the needs of the home cluster with the solution the blogger is writing for.

Any business's needs are vastly different. One might simply want an online presence. Another might want to securely distribute tax documentation to their employees. Another still might want to track their seed-planting drones in real-time. Every use case is different, and so is the complexity of creating it.  

Cloud providers provide a shortcut around complexity by offering services or pre-built infrastructure.  Oftentimes, it’s necessary to buy both, and the costs begin to stack up.  Generally speaking, the "compute" icon (highlighted in orange in the screen grab above) is capable of doing all the rest of the services listed around it.  Compute can host containers, compute can run media services, and compute can accomplish blockchain.  The reason those other services exist is because they represent another layer of convenience — at a higher premium.

Another reason why my cloud development is not “fast” is that I'm approaching a home cluster from a developer background and not as a Developer Operations professional.  In my career, it’s not uncommon to build a piece of software and hand it off to a DevOps team to set up the infrastructure in order to make it all work.

Hypothetically, if I want my website to have a search feature that can figure out if a user is misspelling their search term, I have two options: I could buy it or build it.  To build it would cost me less money but more time.  Let’s examine what that would look like.

To make a user’s search result understand mistyped or misspelled words, I will need a certain kind of database to store a copy of my web content to search against.  I will also need a way to keep that database up-to-date with the ever-changing content on my site so that the search results reflect the entirety of web content.  In this example, I would build out a tool that pushes new content to a database.  A separate DevOps team would make sure that the database is in working order for me on a server somewhere, fixing misspelled words at a snappy pace.  While we see teams work this way, there is often room for overlap.

Cheap

According to my calculations, my cluster is (or will be) worth about $6k/month in cloud costs. This is based on the fantastic article on coddinghorror.com. Roughly 32 CPUs on demand; is it worth $6k/month? That computation power is roughly the equivalent of four powerful Macbooks. Any coffee shop in Seattle will have more computing power than that connected to its Wi-Fi at virtually any time of day. So why is it so expensive?  

The cloud is expensive because data travels at a shorter distance and travels at a faster speed. Also, there is a premium for setting everything up. Finally, because of the expertise put into the setup, they can offer service level agreements (SLAs) to guarantee quality of service.

A system in the cloud doesn’t connect to a consumer Internet Service Provider (ISP).  Cloud providers are hooked into the fastest connections and make fewer hops to get to where they are connecting.

I’m using my ISP to serve my content.  I hate my ISP, but I hate them less than its competitor.

My garage cloud solution is cheap because:

• I am doing it as a hobby project.

• It does not have a monthly fee outside of consumer internet costs.

• It utilizes inexpensive hardware.

Cutting The Right Corners

The Raspberry Pi is a $25 computer, and I've been addicted to it for some time. It is another example of cheap and good but not fast. The cost can be kept low because of the typical interfaces used to interact with the computer. There is no operating system, hard drive, monitor, or keyboard. It's a computer with the niceties stripped out and is perfect for creating a DIY cloud. 

Everything Is Free

Open source is free software—free as in freedom, not free as in "free beer."  Everything I want to accomplish is community-driven and available without charge. A non-comprehensive list can be found here on GitHub under the title awesome-selfhosted.

Is free software good?  I argue it's better.  Linux is an open-source operating system that runs the cloud.  The cloud isn't Windows or Mac OS; it's Ubuntu.  All cloud providers make money off of free community products.

The fact is, capitalism doesn't promote competition; it stomps out competition. Did market competition make Zoom better than Skype? I believe that Skype used its anti-competitive practices to remain an awful product, long enough for the world to be happy to receive an alternative. I'd rant about this further, but it's a digression for another time.

The short lesson is that it can be more expensive to make decisions for yourself.   If a person doesn’t agree with YouTube’s terms of service (TOS), they could host their own YouTube instance.  Another example similar to Skype is Jitsi.  Jitsi is a free alternative to video conferencing — if you have the time and knowledge to set it up.

Experience Counts

When architecting complex systems in a business, a group discussion inevitably occurs to decide whether to build or outsource a service. Building takes man hours, and outsourcing takes money. This is the essential logic behind fast or cheap.

When building this garage VPS of Raspberry Pis, I will use my experience to help me figure out the parts I don’t understand yet. DIY means that I’m not being charged for DevOps labor.

Working as a developer at various startups, I’ve ended up wearing a lot of hats.  In addition to writing software, it’s been my responsibility to keep the servers online, debug problems in the cloud (including ones I wasn’t at fault for), and strip out systems in favor of completely different systems.  These are the very things that one must do to maintain one's own network.

DIY means that I am going to make mistakes.  I am certain that I’ll mess something up and have to start all over again with some or all of the systems.  Because this project is a hobby to learn, I’m not worried about falling into gumption traps over mistakes.

Having maintained systems in the past, I am certain that I will be adding processes that will keep data loss at a minimum. Everyone learns the hard way, and backing up data first will save on headaches later. I have already been using software to automate some processes. I’ve also been keeping track of industry best practices.

Conclusion

This journey is destined to become more technical.  I hope you will want to come along.

Normally, I would just “get to work” and start putting all the pieces together like a mad scientist. At this moment, however, I enjoyed making myself write—not just write, but write out the high-level concepts to forge a raison d'être.

The next step is to enumerate exactly what I want to accomplish. Afterward, I will set about creating tasks that I can consume to make the workload less daunting. Thank you for reading and claiming your cloud!