La tecnología detrás de nuestros nuevos área de cliente y Site Tools

Recientemente hemos anunciado el lanzamiento de nuestros nuevos área de cliente y Site Tools. Nuestro COO habló sobre ello desde una perspectiva empresarial y lo importante que es este proyecto para poder crecer en el futuro. Me gustaría dar una perspectiva técnica y la razón por la que vemos que estas nuevas interfaces pueden ser un hito técnico para SiteGround.

SiteGround siempre ha sido ante todo una empresa de servicios. Sin embargo, durante muchos años, el crecimiento de nuestro negocio se ha correlacionado estrechamente con nuestra evolución técnica. Mientras más software desarrollamos internamente, más aumentaba la calidad de nuestro servicio y más crecía nuestra reputación. No solo eso, sino que hemos aumentado nuestra autoconfianza como compañía de tecnología superior que produce soluciones de software potentes e inteligentes y siempre está entre las primeras en implementar las tecnologías más innovadoras.

Entonces, cuando nos dimos cuenta de que muchas de nuestras ideas de negocio se ralentizaron o se hicieron imposibles debido a las limitaciones de nuestra plataforma actual, tuvimos el coraje de pensar en algo más grande de lo que está disponible en el mercado y nos atrevimos a crearlo desde cero.

El reto

Desde una perspectiva empresarial, queríamos administrar una plataforma (front-end y back-end) que funcionara en cualquier dispositivo, tuviera una apariencia moderna, fuera liviana, rápida, segura y fácilmente escalable. Traduciendo eso en términos técnicos, definimos los siguientes objetivos:

1. Velocidad y UX avanzado

Decidimos usar una aplicación de página única, ya que ésa es LA tecnología imprescindible para una experiencia web más rápida.

2. Escalabilidad y seguridad 

Decidimos adoptar la filosofía de microservicios y hacer que todo esté basado en API para que el sistema pueda escalar más fácilmente y en caso de incidentes tener un alcance de daños menor.

Sin embargo, cuando tienes muchos servicios, la autenticación y la autorización son un gran problema. Por lo tanto, necesitábamos una solución segura, rápida y fácil para el problema de intercambio de recursos de origen cruzado, donde elegimos usar tokens web JSON.

Operar a escala cuando tienes millones de sitios alojados en cientos de miles de contenedores también requiere orquestación, descubrimiento de servicios y una capa de mensajería de confianza donde introducimos Consul y NSQ.

Finalmente, una buena observabilidad, monitoreo y alertas son cruciales dada la complejidad del sistema. Entonces ponemos a Prometheus y Grafana en acción.

Las soluciones

1. Aplicaciones de página única con React y Redux

Hace tres años, cuando comenzamos a trabajar en el proyecto, sabíamos que las aplicaciones de página única se estaban volviendo cada vez más populares porque permitían una mejor experiencia del usuario, tiempos de carga de página más rápidos, la unificación de principios de diseño, diseño modular y más. El ecosistema SPA también estaba evolucionando rápidamente. Había muchos marcos JavaScript como AngularJS, ReactJS y Vue.js. Parecía natural y obvio que cuando se trataba de algo liviano, rápido y basado en API, la aplicación de página única era la respuesta. Después de algunas pruebas con diferentes marcos, decidimos usar ReactJS + Redux para nuestros nuevos área de cliente y Site Tools, ya que mostró los mejores resultados de rendimiento.

Carga rápida de páginas 

Tenemos dos aplicaciones principales de página única. Una es la aplicación para el área del cliente, y la otra es nuestra aplicación para Site Tools. Ambas son utilizadas cada hora por miles de personas y creciendo. Mover parte de la lógica de la aplicación a los navegadores de los usuarios, donde JS se ejecuta localmente, aceleró las cosas. Parte de esto es porque realizamos menos manipulación de datos en el back-end. La otra parte viene del hecho de que nuestras aplicaciones funcionan con una solución de almacenamiento en caché de objetos con CDN al frente. Esto hace que sea muy rápido para los usuarios de todo el mundo cargar rápidamente la aplicación y comenzar a usarla.

Guía de estilo unificada

Las aplicaciones de página única te permiten trabajar con componentes listos que son reutilizables y hacer que sus interfaces sigan ciertos estándares. Para las nuestras, escribimos una guía de estilo, que hace que nuestras interfaces sean homogéneas y nos permite escribir código nuevo de manera más fácil y rápida. ¡La desventaja es que solo el repositorio de la guía de estilo con todos los ejemplos es de aproximadamente 550.000 líneas de código!

Como nuestro desarrollo es bastante grande y está creciendo, y el código con el que trabajamos es bastante voluminoso, necesitábamos asegurarnos de que nuestros estándares se cumplían y no se veían afectados por cambios. Es por eso que cubrimos el código con pruebas Visual y e2e (Cypress). Si un cambio de código modifica visualmente una determinada página de manera significativa, aparece una bandera roja e incluso podemos detener automáticamente la implementación y las compilaciones de código.

2. RESTful APIs y microservicios

Ahora tenemos más de 100 llamadas API que se pueden usar para administrar un solo sitio alojado en nuestros servidores. Cosas como instalar WordPress, emitir un certificado SSL privado, crear cuentas de correo, crear nuevas bases de datos MySQL, agregar claves SSH e incluso migrar sitios entre servidores se realizan a través de llamadas API. Lo que nos dan estas APIs son los siguientes beneficios:

Fomenta el uso de idiomas diferentes 

Tenemos ingenieros de software que escriben en los siguientes lenguajes/frameworks para nuestra plataforma: 

  • PHP (Symfony, Zend Framework)
  • Perl (Dancer)
  • Go
  • Python
  • JavaScript (ReactJS, AngularJS), TypeScript 

Para asegurarnos de que todas las partes puedan comunicarse entre sí, necesitábamos API RESTful para servir de puente en la comunicación.

El reconocido diseño de RESTful API

Lo bueno de las RESTful APIs es que casi cualquier desarrollador hoy en día las comprende y está familiarizado con el concepto. Esto significa que cuando necesitamos agregar nuevas funciones no tenemos que formar a los desarrolladores o hacerles aprendan los entresijos de todo el sistema para que puedan realizar el trabajo. Simplemente pueden centrarse en la nueva pieza de código necesaria e integrarla en el sistema.

Nuestros socios pueden usar las APIs

El hecho de que todo esté basado en API facilita el acceso a los socios y les permite crear sitios, instalar un CMS o realizar otras funciones en nuestra plataforma. Eso nos hace flexibles y es una buena base para nuestro futuro crecimiento empresarial.

Acceso personalizado para el usuario 

Las API RESTful aplican el principio CRUD que dice que cada objeto manipulado por la API debe soportar las siguientes 4 funciones: crear, leer, actualizar y eliminar. Junto con la representación unificada de recursos REST, esto permite una fácil segregación de acciones y un acceso personalizado y control del usuario.

Junto con los JSON Web Tokens, utilizamos las API para proporcionar niveles de acceso personalizados en nuestras nuevas interfaces. Ahora es posible permitir que un operador cree cuentas de correo para un nombre de dominio, pero no tener acceso a las cuentas de correo existentes ni a ninguna otra herramienta. Para empezar, hemos introducido solo 3 roles de usuario: propietario del sitio, colaborador y cliente de marca blanca, pero hemos sentado las bases para agregar fácilmente muchas opciones de personalización en el futuro. El control de acceso basado en roles nos permite proporcionar acceso granular a servicios y características específicos.

Identificar problemas más fácilmente y medir mejor

Cuanto más granular es la construcción, más fácil es aislar una parte disfuncional y reemplazarla o arreglarla. Ése es uno de los principales beneficios que vemos de la filosofía de microservicios. Podemos rastrear y solucionar problemas más fácilmente con una función específica proporcionada por un servicio específico. También podemos realizar un mejor seguimiento del rendimiento y el uso de los diferentes servicios para poder escalar los recursos de la plataforma y evitar problemas.

3. JSON Web Tokens

En el momento en que comenzamos a trabajar en aplicaciones de página única, sabíamos que teníamos que escalar nuestra configuración de autenticación y autorización de alguna manera. Dada la cantidad de APIs que se comunican entre sí y de los usuarios que también interactúan con estas APIs (que se distribuyeron en diferentes dominios), la autorización se hizo a la antigua usanza: a través de cookies no era óptimo ni escalable. Los dos problemas principales que tuvimos fueron:

  • Tratar las cookies de intercambio de recursos de origen cruzado y cabeceras HTTP no es simple y queríamos evitarlo. La combinación de JSON Web Tokens con nuestras propias APIs nos permite resolver este problema.
  • Escalar un sistema back-end que verifica cada solicitud API comenzó a ser terrible desde el punto de vista del rendimiento de las sesiones.

Después de un poco de investigación, decidimos usar JSON Web Tokens para esta parte de la infraestructura. Nosotros configuramos un sistema de autenticación y autorización personalizado. Nos permite beneficiarnos de cosas como:

  • Mecanismo de autorización uniforme para diferentes APIs
  • Reducción de la carga del servidor y menos llamadas a la base de datos
  • Posibilidad de usar esta solución en diferentes dominios
  • Mayor facilidad para lograr escalabilidad horizontal
  • Un mayor nivel de seguridad para nuestros usuarios.
  • Un innovador inicio de sesión único

4. Orquestación y mensajes 

Cuanto más crecemos, más servidores (como unidad de hardware) y contenedores (como unidad virtual) operamos. El contenedor Linux es la unidad principal de nuestra infraestructura, pero la forma en que administramos estos contenedores está cambiando. Solicitar nuevos servidores, implementar un contenedor con la pila de software necesaria, agregar ese nuevo contenedor a todas las bases de datos que alimentan diferentes servicios y APIs, todo eso y más requiere orquestación. Para esta parte, hemos escrito mucho código, específico para nuestra plataforma y procesos. Aún así, dependemos en gran medida de proyectos de software bien establecidos para lograr nuestros objetivos. Utilizamos HashiCorp Consul para el descubrimiento de servicios y la automatización de sistemas. Nuestra plataforma de mensajería preferida es NSQ. Utilizamos Ansible para automatizar muchas tareas de administración de configuración y aprovisionamiento de software.

Dos buenos ejemplos son nuestros sistemas rediseñados de actualizaciones automáticas Let’s Encrypt y WordPress. Solían ejecutarse localmente en cada servidor de hosting y ahora se basan en un enfoque distribuido. Los servidores se registran automáticamente en el sistema. Los servicios utilizan el descubrimiento automático proporcionado por Consul. Luego, se utilizan las APIs mencionadas anteriormente y se produce la emisión y renovación de SSL para cada nuevo nombre de dominio que registramos en el sistema. Lo mismo es válido para cada aplicación que entra en los sistemas de actualizaciones automáticas de WordPress.

5. Prometheus/Grafana para la observabilidad

La forma en que ofrecemos los nuevos servicios también ha cambiado mucho. En el mundo nativo de la nube ya no nos importan los fallos de los hosts individuales. No se llama a ningún ingeniero del centro de operaciones (NOC) cuando esto pasa. No hay administradores de sistemas artesanales que traten las máquinas y los servicios con una atención delicada. Ahora supervisamos toda la infraestructura con los siguientes objetivos en mente:

  • Tenemos que saber cuando las cosas van mal
  • Podemos depurar y tener una idea sobre el contexto específico
  • Tenemos que poder ver los cambios en el tiempo y hacer predicciones
  • La información tiene que ser fácil de consumir por otros sistemas y procesos

Para que lo dicho anteriormente sea más específico, ahora estamos redefiniendo los escenarios de "fallos" y las alertas que recibimos para cada uno. Por ejemplo, podemos recibir alertas que requieren interacción humana cuando hay un impacto directo en el usuario, como cuando se ve afectado un servicio que afecta directamente los sitios web de los clientes. Pero es posible que no necesitemos intervención humana cuando un nodo específico ha fallado, ya que los datos se redistribuyen automáticamente en otros nodos y no hay impacto en el usuario, por lo tanto, no se necesita alerta en este caso.

Cuando trabajamos en esas alertas, nuestro objetivo es pasar de la alerta a los subsistemas problemáticos. Para que nuestros ingenieros hagan un análisis rápido y ofrezcan una resolución rápida, debemos tener suficientes datos. Esto se llama rastreo distribuido y nos permite seguir las solicitudes específicas de los usuarios desde los navegadores de nuestros clientes, a través de múltiples APIs y diferentes servicios, hasta que llegan a las bases de datos y/o motores de almacenamiento. Cada registro sobre una solicitud en el sistema de rastreo distribuido nos brinda información de perfil de rendimiento y una forma de correlacionar problemas con otros eventos. Utilizamos el rastreo distribuido para depurar y optimizar más rápido nuestro código. Gracias a eso, podemos lograr una mayor velocidad de la función.

Para lograr todos los objetivos, elegimos usar Prometheus y Grafana para la creación de perfiles, la recopilación de métricas, el análisis de registros y el seguimiento distribuido de eventos. Ahora podemos correlacionar información de múltiples fuentes y revelar y predecir deficiencias.

Conclusión

El software que tuvimos que escribir para abordar el desafío y proporcionar las soluciones mencionadas anteriormente es enorme, pero bastante gratificante. Para concluir, te dejaré con algunos números de los nuevos repositorios de software y nuestro JIRA:

  • 2.539.604 líneas de código
  • 99% pruebas de cobertura de código 
  • 9.250 tareas JIRA 
  • 199.560 palabras en historias de JIRA 

Estamos particularmente orgullosos de nuestras pruebas de cobertura de código. Aunque 2.5 millones de líneas de código son impresionantes, sabemos que ésta no es una gran medida de éxito. Sin embargo, el hecho de que todo nuestro código esté cubierto por las pruebas es un gran logro. Desde el principio, establecemos las pruebas de cobertura de código como uno de nuestros criterios principales para proporcionar software de calidad. Y si nuestros nuevos área de clientes y Site Tools no pueden proporcionar garantías de calidad, entonces no podemos ofrecer el increíble servicio al que nuestros clientes están acostumbrados. Ten la seguridad de que estamos dedicados a proporcionar el mismo servicio de hosting de primer nivel, pero esta vez con mejores herramientas de administración y colaboración del sitio, basadas en las mejores y más innovadoras tecnologías web del mundo.

Un comentario

  1. Contestar octubre 24, 2019 / 13:18 Sergio ArreguiEquipo SiteGround

    En un principio me enfadé bastante porque estaba acostumbrado al CPANEL.
    Pero ya le voy cogiendo el truquillo.
    Buen trabajo
    slds

Contestar

* (Requerido)