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.