How I Built a Private Cloud: Experience and Architecture

Disclaimer

This publication may contain strong language and materials that may be inappropriate for some readers. The content is intended for readers aged 27 and older. If you are sensitive to harsh expressions or similar elements, we recommend refraining from reading further.

The author and editorial team are not responsible for any negative reactions caused by the use of profanity in this text. The use of such language serves artistic or stylistic purposes and is not intended to offend or humiliate anyone.

You read this at your own risk. All characters and events are real. All stunts performed by professionals.

Introduction

At the end of 2021, I was offered a project to build a private cloud. The key question was simple: “Do you know Ruby on Rails?” — I did. I agreed without much hesitation.

At First, It Was Interesting

It all started with an acquaintance with a lazy but experienced system administrator on the organization's side, an architect, and a senior on the integrator's side. They seemed kind and fun, and we began exploring an open-source concoction from Red Hat that we had chosen as the foundation for our cloud. We examined the code, the architecture, the provided frameworks, and proposed solutions. I suggested building a client-facing control panel, which was accepted without objections.

On my end, I assembled an MVP of the portal, the integrator wrote the part responsible for vmWare integration, and after a successful demo, leadership high-fived. But to me, it was clear: this was only the beginning. After hiring a frontend dev, we continued developing the cloud and integrating the system into production.

Import Substitution and Stress Testing

Then came the sanctions, and the next stage involved testing the "import-substituted" virtualization management system. Meanwhile, we were hiring: sometimes interesting people would come in, but they quickly left.

By summer 2023, new leadership pushed through an inappropriate hire. Around this time, our frontend dev left, and the team started being built from random people.

Then — A Zoo

Juniors with unexpected habits began to fill the team. One couldn’t hear tasks, another barely spoke at all. The sysadmin burned out and quit, while on paper, needs were being “met” and an illusion of vigorous activity was created. Meanwhile, the infrastructure was growing. But work communication within the team had completely broken down.

By the end of the another integrator's term in 2024, less than half of the deliverables from the original spec were implemented. There was no internal specification at all. Time was lost, the project stagnated, and the team was demotivated. A copy of “7 Habits of Highly Effective People” collected dust on a shelf. Expectation vs. reality.

Straight to Hell and Back

After the New Year break, attempts to stir conflict became a management tactic — a mass one. Work ground to a halt, and trust hit zero. That shaped the policy of future interactions.

The project ceased to be technical, completely shifting course to horror-vibe management. Line managers, having seized power, played it off as best they could — through control, fear, and sabotage. They understood neither people nor systems, and some reveled in their signing authority, as if it made them competent.

On the Edge

From the outside, it might appear that the system is working — over 3.5 years, more than 5,000 virtual machines have been created, and there have been no critical failures. This was an illusion of stability. They decided to replace me with a PHP programmer, apparently thinking that clouds grow from index.php.

Bishop's Move

The pawns, having started playing cards, did not notice how they were being removed one after another. But the figures were playing chess, and the bishop, having received the system's assistance report, made its move.

To be continued...