Hello! We are 'Hosting Technologies' and we launched ā the first VDS hosting specifically designed for developers five years ago. We aim to make it as convenient as DigitalOcean, but with Russian support, payment methods, and servers located in Russia. But DigitalOcean is not just about reliability and price; it's also about service.
The software from ISPsystem turned out to be a rope that tied our hands on the way to providing great service. Three years ago, we used billing with Billmanager and server management with VMmanager and quickly realized that it was almost impossible to provide good service without our own panel.
How ISPsystem hindered convenience
Bugs
We couldnāt fix bugs ourselvesāeach time, we had to write to external support and wait. Resolving any issue required a response from a third-party company.
ISPsystem's support responded adequately, but fixes only came after several releases, and that was not always the case. Sometimes, critical bugs would take weeks to resolve. We had to calm our clients, apologize, and wait for ISPsystem to fix the bug.
The threat of downtimes
Updates could lead to unpredictable downtimes that triggered new errors.
Every update felt like a lottery: we had to suspend billing and make sacrifices to the gods of updatesāon a couple of occasions, updates caused downtimes of 10-15 minutes. Our admins were on edge during this timeāwe never knew how long the downtime would last and couldnāt predict when ISPsystem would decide to release a new update.
With the fifth generation of Billmanager, things improved a bit, but to access the necessary features, we had to install a beta version that was updated weekly. If something broke, we had to give access to external developers to make corrections.
Inconvenient panel interface
Everything was divided across different panels and managed from various locations. For instance, clients made payments through Billmanager, while they had to reboot or reinstall VDS in VMManager. Our staff also had to switch between windows to assist clients, check server loads, or see what OS they were using.
Such an interface wastes timeāboth ours and our clients'. Convenience, like that of DigitalOcean, is not even a consideration in this situation.
Short lifecycle with frequent API updates
We developed our own plugins ā for example, a payment plugin with additional payment methods not available in VMManager.
In recent years, VMManager has had a relatively short lifecycle, with variable or function names in the API changing arbitrarily in new versions ā breaking our plugins. Support for older versions was quickly phased out, forcing us to upgrade.
Can't modify
More precisely, you can, but it's extremely inefficient. Licensing restrictions prevent changes to the source code; you can only write plugins. The maximum for plugins includes some menu elements and a step-by-step wizard. ISPsystem is designed for universality, but we needed specialized solutions.
This led us to the decision to write our own panel. We set the following goals:
- Quickly respond to errors, bugs, and have the ability to resolve them independently without making the client wait.
- Freely modify the interface according to the client's workflows and needs.
- Improve usability with a clean and clear design.
And we started development.
Architecture of the new panel
We have a self-sufficient development team, so we wrote the panel ourselves.
The main work was done by three engineers ā the technical director Sergey devised the architecture and wrote the server agent, Alexey handled billing, and our frontend was assembled by Artysh.
Step 1. Server Agent
The server agent is a web server written in Python that manages the library , which, in turn, manages .
The agent manages all services on the server: creating, stopping, deleting VDS, installing operating systems, changing parameters, and so on through the libvirt library. At the time of publication, there are more than forty different functions that we supplement depending on tasks and client needs.
In theory, libvirt could be managed directly from billing, but it required too much additional code, and we decided to separate these functions between the agent and billing ā billing simply makes requests to the agent via the JSON API.
The agent was the first thing we developed since it didn't require any interface, and we could test it directly from the server console.
What the server agent has given us: A layer has emerged that simplifies life for everyoneābilling no longer needs to transmit a whole bunch of commands, just make a request. And the agent will handle everything needed: for example, allocating disk space and RAM.
Step 2. Billing
For our developer Alex, this was not his first control panelāAlex has been in hosting for a while, so he understood what the client needed and what the host needed.
We refer to billing among ourselves as the 'control panel': it includes not only money and services but also management of them, customer support, and much more.
To transition from the ISPSystem software, it was necessary to completely retain the previous functionality for clients, transfer all users' financial transactions from the old billing to the new one, and also all the services and their connections. We investigated what was in the current product, then looked at competitors' solutions, mainly DO and Vultr. We examined the drawbacks and advantages, gathered feedback from people who had worked with old ISPsystem products.
In the new billing, we used two stacks: classic PHP, MySQL (and we plan to move to PostgreSQL in the future), Yii2 as the framework on the backend, and VueJS on the frontend. The stacks work independently from each other, developed by different people, and communicate via a JSON API. For development then and now, we use and from JetBrains and we love them dearly (hi guys!)
The panel is designed modularly: payment system modules, domain registrar modules, or, for example, SSL certificate modules. It's easy to add new features or remove old ones. The architectural design allows for expansion, including backward compatibility, 'to the hardware.'
What we achieved: a control panel over which we have full control. Bugs are now fixed in hours, not weeks, and new features are implemented at the request of clients, not at the behest of ISPSystem.
Step 3. Interface
The interface is our teamās brainchild.
Initially, we looked at what would happen if we built an overlay over the ISPsystem API without making any drastic changes to the interface. It turned out mediocre, and we decided to start everything from scratch.
We believed that the key was to create a logical interface with a clean and minimalist design, resulting in a beautiful panel. The placement of elements was discussed in Megaplan, gradually giving rise to the interface that users see in the control panel today.
The first design was for the billing page, as we had already developed payment plugins for ISPsystem.
Frontend
We decided to make the panel a SPA applicationāresource-efficient with fast data loading. Our frontend developer, Artysh, chose to write it in Vue, which had just emerged at that time. We assumed the framework would develop dynamically like React, and eventually, the Vue community would grow, leading to a multitude of libraries. We placed our bets on Vue and have not regretted itāadding new features to the frontend that we have already programmed on the backend now takes little time. We will discuss the panel's frontend in a separate article.
Connecting Frontend and Backend
The frontend was connected to the backend through pushes. It took some effort to write our own handler, but now the information on the page updates almost instantly.
What we achieved: The panel interface became simpler. We made it responsive, and the fast loading allows users to access it even from mobile devices in the last minutes before takeoff, without needing a separate app to work with the panel.
Step 4. Testing and Migration Scheme
Once everything was up and the initial tests were completed, the issue of migration arose. First, we set up the billing system and began testing its interaction with the server agent.
Then we created a simple script that transfers the database from the old billing system to the new one.
We had to test and double-check literally everything, as the data was merged into a new database from three old ones: Billmanager, VMmanager, and IPmanager. Perhaps, test migrations were the most complicated aspect we faced during the development of the new panel.
After thorough checks, we shut down the old billing system. The final data migration was a very anxious moment, but thankfully, it was completed in a few minutes without any noticeable problems. There were minor bugs that we fixed over the course of a week. Most of the time was spent testing what we had achieved.
Then we sent emails to clients with the address of the new panel and billing, and made a redirect.
As a result: ITāS ALIVE!
Happy Ending
From the first hours of operating our software, we felt all the benefits of the transition. The code was completely ours and had a convenient architecture, while the interface was clean and logical.
First feedback after launching the new panel
We started the transition process in December, just before the New Year 2017, when the load was at its lowest to make the transition easier for clients ā almost no one works before the holidays.
The main thing we gained from transitioning to our own system (besides overall reliability and convenience) is the ability to quickly add functionality for key clients ā to be their face, not their backside.
What's next?
We are growing, the amount of data, clients, and client data is increasing. We had to add a Memcached server and two queue managers with different tasks to the backend. On the frontend, there is caching and our own queues.
Of course, we had adventures as we developed and complicated the product, for example, when we added HighLoad.
In the next article, we will talk about how we launched the Hi-CPU plan: about the hardware, software, the tasks we solved, and what we achieved.
Source: habr.com
