¡Hola! Somos 'Tecnologías de Hosting' y hace 5 años lanzamos — el primer hosting vds creado específicamente para desarrolladores. Nos esforzamos por hacerlo tan conveniente como DigitalOcean, pero con soporte en ruso, métodos de pago y servidores en Rusia. Pero DigitalOcean no es solo fiabilidad y precio, también es servicio.
El software de ISPsystem resultó ser una cuerda que ataba nuestras manos en el camino hacia un gran servicio. Hace tres años utilizamos la facturación Billmanager y el panel de control de servidores VMmanager y rápidamente nos dimos cuenta de que ofrecer un buen servicio sin nuestro propio panel era prácticamente imposible.
Cómo ISPsystem mataba la comodidad
Errores
No podíamos arreglar los errores por nuestra cuenta; cada vez teníamos que escribir al soporte de otros y esperar. La resolución de cualquier problema requería la reacción de una empresa externa.
El soporte de ISPsystem respondía de manera normal, pero las soluciones llegaban solo después de varias versiones, y no siempre y no todos los errores. A veces, errores críticos tardaban semanas en ser resueltos. Teníamos que calmar a los clientes, disculparnos y esperar a que ISPsystem reparara el error.
Amenaza de caídas
Las actualizaciones podían provocar caídas impredecibles, que a su vez causaban nuevos errores.
Cada actualización era una lotería: había que cerrar la facturación y hacer sacrificios a los dioses de las actualizaciones; un par de veces, la actualización causó una caída de entre 10 y 15 minutos. Nuestros administradores estaban al borde del colapso; nunca sabíamos cuánto duraría la caída y no podíamos prever cuándo ISPsystem lanzaría una nueva actualización.
Con la quinta generación de Billmanager mejoró un poco, pero para acceder a las funciones necesarias tuvimos que instalar la beta, que ya se actualizaba cada semana. Si algo fallaba, había que dar acceso a desarrolladores externos para que arreglaran algo.
Interfaz del panel incómoda
Todo estaba dividido en diferentes paneles y gestionado desde distintos lugares. Por ejemplo, los clientes pagaban a través de Billmanager, pero tenían que reiniciar o reinstalar su VDS en VMManager. Nuestros empleados también tenían que cambiar entre ventanas para ayudar al cliente, verificar la carga en su servidor o ver qué SO utilizaba.
Tal interfaz consume tiempo, tanto el nuestro como el de los clientes. No se puede hablar de comodidad, como en DigitalOcean, en una situación así.
Ciclos de vida cortos con actualizaciones frecuentes de la API
Escribimos nuestros propios complementos, por ejemplo, un complemento con métodos de pago adicionales que no están en VMManager.
En los últimos años, VMManager ha tenido un ciclo de vida relativamente corto, y en nuevas versiones, los nombres de las variables o funciones en la API podían cambiar arbitrariamente, lo que rompía nuestros complementos. El soporte para versiones antiguas se descontinuaba rápidamente y había que actualizar.
No se puede modificar
En realidad, sí se puede, pero es extremadamente ineficiente. Las restricciones de licencia no permiten modificar el código fuente, solo se pueden escribir complementos. El máximo de complementos son algunos elementos de menú, un asistente paso a paso. ISPsystem está diseñado para la versatilidad, pero nosotros necesitábamos soluciones especializadas.
Así nació la decisión de escribir nuestro propio panel. Nos propusimos objetivos:
- Responder rápidamente a errores y bugs y tener la capacidad de solucionarlos por nuestra cuenta, sin hacer esperar al cliente.
- Modificar libremente la interfaz según los procesos de trabajo y necesidades del cliente.
- Mejorar la usabilidad con un diseño limpio y comprensible.
Y comenzamos el desarrollo.
Arquitectura del nuevo panel
Tenemos un equipo de desarrollo autosuficiente, por lo que el panel lo escribimos nosotros mismos.
El trabajo principal lo realizaron tres ingenieros: el director técnico, Sergey, ideó la arquitectura y escribió el agente del servidor, Alexey se ocupó de la facturación, y nuestro frontendista, Artysh, armó el frontend.
Paso 1. Agente del servidor
El agente del servidor es un servidor web en Python que gestiona la biblioteca , que a su vez gestiona .
El agente gestiona todos los servicios en el servidor: creación, detención, eliminación de VDS, instalación de sistemas operativos, modificación de parámetros, etc., a través de la biblioteca libvirt. En el momento de la publicación de este artículo, hay más de cuarenta funciones diferentes, que complementamos según las tareas y necesidades del cliente.
En teoría, se podía gestionar libvirt directamente desde la facturación, pero eso requería demasiado código adicional y decidimos separar estas funciones entre el agente y la facturación: la facturación simplemente hace solicitudes al agente a través de la API JSON.
El agente fue lo primero que hicimos, ya que no requería ninguna interfaz y se podía probar directamente desde la consola del servidor.
¿Qué nos aportó el agente del servidor? se ha creado una capa que simplifica la vida de todos: la facturación no necesita enviar un montón de comandos, solo hacer una solicitud. Y el agente hará todo lo necesario: por ejemplo, asignará espacio en el disco y memoria RAM.
Paso 2. Facturación
Para nuestro desarrollador Alex, este no era su primer panel de control: Alex ha estado en el hosting durante mucho tiempo, por lo que comprendía en general lo que necesitaba el cliente y lo que necesitaba el host.
Nosotros llamamos a la facturación entre nosotros "panel de control": no solo se trata de dinero y servicios, sino también de su gestión, soporte al cliente y mucho más.
Para migrar desde el software ISPSystem, era necesario conservar completamente la funcionalidad anterior para los clientes, trasladar todas las acciones financieras de los usuarios del antiguo sistema de facturación al nuevo, así como todos los servicios y las conexiones entre ellos. Estudiamos lo que hay en el producto actual, luego las soluciones de la competencia, principalmente DO y Vultr. Observamos las desventajas y ventajas, recopilamos los comentarios de las personas que trabajaron con los antiguos productos de ISPsystem.
En el nuevo sistema de facturación utilizamos dos pilas: PHP clásico, MySQL (y en el futuro planeamos pasar a PostgreSQL), Yii2 como marco en el backend y VueJS en el frontend. Las pilas funcionan de manera independiente entre sí, son desarrolladas por diferentes personas y se comunican mediante JSON API. Para el desarrollo, en aquel entonces y ahora, usamos y de JetBrains y los amamos mucho (¡hola, chicos!)
El panel está diseñado de manera modular: módulos de sistemas de pago, módulos de registradores de dominios o, por ejemplo, módulos de certificados SSL. Se puede agregar fácilmente una nueva función o eliminar una antigua. La arquitectura está preparada para la expansión, incluyendo hacia atrás, "hacia el hardware".
Lo que obtuvimos: un panel de control sobre el que tenemos control total. Ahora, los errores se corrigen en horas, no en semanas, y las nuevas funciones se implementan a pedido de los clientes, no por deseo de ISPSystem.
Paso 3. Interfaz
La interfaz es nuestro proyecto conjunto.
Primero miramos qué pasaría si hiciéramos una extensión sobre la API de ISPsystem, sin cambiar nada drásticamente en la interfaz. El resultado fue mediocre y decidimos hacer todo desde cero.
Creímos que lo principal era hacer que la interfaz fuera lógica, con un diseño limpio y minimalista, y así obtendríamos un hermoso panel. Discutimos la disposición de los elementos en Megaplan y poco a poco nació la interfaz que los usuarios ven en el panel de control ahora.
El diseño de la página de facturación fue el primero, ya que ya habíamos creado plugins de pago para ISPsystem.
Frontend
Decidimos hacer el panel como una aplicación SPA, que no requería muchos recursos y cargaba datos rápidamente. Nuestro frontend, Artysh, decidió escribirlo en Vue; en ese momento, Vue acababa de aparecer. Supusimos que el marco se desarrollaría dinámicamente, al igual que React, y con el tiempo la comunidad de Vue crecería y habría un montón de bibliotecas. Apostamos por Vue y no nos arrepentimos; ahora, agregar nuevas funciones al frontend que ya hemos programado en el backend lleva poco tiempo. Hablaremos más sobre el frontend del panel en un artículo separado.
Conexión del frontend con el backend
Conectamos el frontend con el backend a través de 'pushes'. Fue un reto escribir nuestro propio manejador, pero ahora la actualización de la información en la página ocurre casi instantáneamente.
Lo que obtuvimos: La interfaz del panel se volvió más simple. La hicimos adaptable y la rápida carga permite usarla incluso desde móviles en los últimos minutos antes del despegue, sin necesidad de instalar una aplicación separada para trabajar con el panel.
Paso 4. Pruebas y esquema de migración
Cuando todo estuvo listo y pasamos las primeras pruebas, surgió la pregunta de la migración. Lo primero que hicimos fue instalar la facturación y comenzar a probar su funcionamiento con el agente de servidor.
Luego escribimos un simple script que transfería la base de datos de la antigua facturación a la nueva.
Tuvimos que probar y verificar casi todo, ya que los datos se consolidaron en una nueva base a partir de tres antiguas: Billmanager, VMmanager e IPmanager. Aparentemente, las migraciones de prueba fueron lo más complicado con lo que nos enfrentamos en el proceso de desarrollo del nuevo panel.
Después de las verificaciones, cerramos la antigua facturación. La migración final de datos fue un momento muy inquietante, pero, gracias a Dios, se realizó en unos minutos y sin problemas evidentes. Hubo pequeños errores que corregimos durante la semana. La mayor parte del tiempo se dedicó a probar lo que habíamos conseguido.
Luego enviamos correos a los clientes con la dirección del nuevo panel y la facturación y realizamos una redirección.
En resumen: ¡ESTÁ VIVO!
Final feliz
Desde las primeras horas de funcionamiento de nuestro software, sentimos todas las ventajas de la transición. El código era completamente nuestro, con una arquitectura conveniente, y la interfaz era limpia y lógica.
La primera reseña tras el lanzamiento del nuevo panel
Iniciamos el proceso de transición en diciembre, justo antes del Año Nuevo 2017, cuando la carga era más baja, para facilitar el cambio a los clientes: casi nadie trabaja antes de las festividades.
Lo más importante que obtuvimos al migrar a nuestro sistema (además de la fiabilidad y la comodidad) fue la capacidad de agregar rápidamente funcionalidad para clientes clave: ser su cara, no su lado oscuro.
¿Qué sigue?
Estamos creciendo, aumentando la cantidad de datos, clientes y datos de clientes. Tuvimos que añadir un servidor Memcached en el backend y dos gestores de colas con diferentes tareas. En el frontend hay caché y nuestras propias colas.
Por supuesto, tuvimos algunas aventuras a medida que desarrollábamos y complicábamos el producto, por ejemplo, cuando añadimos HighLoad.
En el próximo artículo, contaremos cómo lanzamos la tarifa Hi-CPU: sobre el hardware, el software, qué tareas resolvimos y qué logramos.
Fuente: habr.com
