The most common way of hosting new services is to rent Virtual Machines (VMs) from Amazon Web Services (commonly called Elastic Compute Cloud or EC2) or Google Cloud Platform (commonly called Google Compute Engine or GCE).

While these are the easiest ways of getting a VM up and running within minutes, these methods have strings attached. Running VMs on AWS or GCE isn’t always the most efficient use of money, especially with startup budgets. It also increases one’s dependence on large cloud providers.

Why do you think so many new Clould Compute companies come up every year even though we already have AWS and GCE? Because there’s enough value left on the table for incumbents to try and lower the margins. The price to performance ratio is also one of worst with the above mentioned companies.

To keep costs in control AND get good performance for our services, we took an unorthodox route (for startups at-least) - build our own mini data-center in-house (ahem.. a single server-rack for starters).

In-house services run by GMetri, the Virtual Reality Company, are the same that most companies need from day 1 to function efficiently: chat (Zulip), storage (Nextcloud), git (Gitea), docker, Video Confernce (Jitsi), centralized login (LDAP), other VMs.

How it all started

Long before we setup our first server-rack, we were already using a few desktop machines like servers. At the time, we used KVM as our hypervisor. All the steps have been detailed in this repo. The biggest hurdle while doing this was setting up the bridge network  to make the VMs behave as if they were standalone servers on our network

Benefits of hosting your own server-rack

• Much better performance than we had ever imagined
• Superb flexibility
• Developer specific VMs, personal Kubernetes clusters. Note: following the “general guidelines” of giving every developer their own VM or a Kubernetes cluster is generally out of scope any startup’s (actual startup, not large companies masquerading as startups) shoestring budgets

Steps involved in setting up the server-rack

1. Purchase a server rack housing, switch, lots of storage, and server system (more about specific configurations in a separate post)
2. Prepare server trays
3. Put the switch, server trays into the server rack. Link up the power and LAN cables

A few pics of the process:

Cluster Management

There were two popular options we compared while deciding which software to use for cluster management - oVirt and Proxmox.

oVirt

oVirt is a open-source virtualisation software founded by Red Hat. It has a steep learning curve and used mostly of large server deployments.

Proxmox

Initially we were sceptical of using Proxmox. But later, the simplicity won us over. For beginners, the WebUI is a life saver, and for advanced tasks there is a suite of commands on command line. The deciding factor for us was the easy setup of Ceph cluster within proxmox. We have a very heavy storage requirement, and it turns out ceph is just what we were looking for. Most of our VMs also run on virtual disks (like EBS) setup using Ceph’s RADOS Block Devices.

Way Forward

I believe that if not for all services, around 70% to 90% non-prod services can easily be ported to one’s own cloud.

Here’s a time-lapse of the whole process

On a closing note, the server rack looks like this currently :). We might soon need to purchase a few more.

H Laws

Hofstadter’s Law:

A task always takes longer than you expect, even when you take into account Hofstadter’s Law.

Hartree’s Law:

Whatever the state of a project, the time a project-leader will estimate for completion is constant.

And then there’s also an “A” law:

Atwood’s Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript. 🔗

It has been really long since I blogged anything. The primary reason was that blogging and searching through the existing blog had become tougher than required. Probably because of Hugo and the theme that I selected in it.

Spent today shifting sahil.cc back from hugo to hexo. Ended up paying a heavy price for not sticking as closely as possible to the Markdown spec (and depending hugo/hexo specific plugins instead).

For Hexo theme, it was a close call between Hexo Next and Icarus. Finally Hexo Next won out for its ease of use.

Now live at https://www.sahil.cc

Always wondered if there is way in SELinux to disable the deadly rm -rf at / path.
Maybe the command rm can be asked by selinux not to allow anyone to run it at / location with the option -rf *?

Could never find the time to experiment in a VM to find out. Have you?
Please let me know through the comments section!

Spent a really long time yesterday trying to figure out how to edit UEFI boot options after my old Intel Core 2 Duo desktop refused to boot up on intstalling LinuxMint 18.3.

Had to learn more than I had bargained for about the EFI FAT32 partition at /dev/sda1 to fix it.
The efibootmgr command proved to be a lifesaver. And so did the script provided in this superuser.com post. May the person who wrote it live long and prosper.

Things being worked on

While going over different technologies that could be used to augment the existing stack in GMETRI (more about that to be written) I came across a number of exciting advancements that occurred in the JS world over the last one and a half year. Focusing on creating a startup and with me becoming a father (for the first time) left me with little time to keep up with the latest tech happenings. This post is an attempt to overcome that.

Motivation

While trying to interpret the nagging feeling that something was missing in the way we developed, I went down to my roots. Why do I think I can code well? This reminded me what some of my most complex and well written pieces of code were — Games. Games traditionally are the most difficult (and exciting) pieces of code to write because both the background complexity and the UI are an order of magnitude more complex than the usual day to day apps we are used to.

Goal

On a personal front am planning to create a simple game to give me a taste of the below tools and frameworks that seem to be missing pieces using this article as a guide. Hopefully yields a good result! ReactNative looks like a good platform to be building it. Also with ReactVR gaining popularity it makes the argument to learn ReactNative and basing all (near term) future development on ReactJS even stronger.

Treasure Hunt

On the tooling front a search on React yielded a gold mine. This article is an opinionated piece on every new building block that I was searching for. Also a very interesting piece of information was that Angular 4 is something that can be seriously looked at for future projects. The only fear is the cost of context switching.

Pieces Missing in our current flow — Solution

• Type Checking — Flow
• State Manager — MobX
• Material Design for React — React Toolbox
• Form validations — FormState
• API Layer: GraphQL
• Frontend API Caching Layer: apollo-client
• Type Checking: Flow/TypeScript 2 (Good comparison)

The above is list that will undergo serious changes once the test game is complete. More on that in another post.

A lot has been written about resizing PNGs and the comparison of different tools that allow it.

The following are my top picks:

My first hugo blog post.

Google analytics gives us the ability to modify tracked through filters. The following screenshot tells us how to modify Request URI and add the hostname to it: