Lo que aprendimos al hacer de código abierto una gran parte de Mailgun

Hace unas semanas, liberamos como código abierto Flanker, nuestra biblioteca de análisis MIME y validación de emails. Estamos muy contentos con el lanzamiento y el nivel de interés que ha mostrado la comunidad de Python. Este tuit refleja muy bien lo que hemos escuchado desde el lanzamiento:

Liberar software como código abierto puede parecer fácil, pero es mucho más complejo que subir tu código a Github y darlo por terminado. De hecho, nos sorprendieron algunos de los retos que nos encontramos. Por eso, queríamos compartir algunos detalles sobre el proceso con la esperanza de ayudar a otros equipos de desarrollo que tengan planes de publicar su propio código. Con ese objetivo, aquí te contamos cómo lo hicimos y lo que aprendimos.

Al principio, nos comprometimos a liberar Guardpost, nuestro validador de direcciones de email. Al empezar, nos dimos cuenta rápidamente de que sería mucho más útil incluirlo en nuestra biblioteca de análisis MIME y publicarlo en un único paquete llamado Flanker. Esto conllevó complicaciones adicionales, ya que estábamos publicando como código abierto una parte bastante grande de la base de código principal de Mailgun.

Como Flanker no se diseñó originalmente para que lo utilizara nadie más, supuso todo un reto asegurarnos de eliminar todas las dependencias de la base de código patentada. No queríamos imponer el uso de tecnologías específicas a nuestra base de usuarios, así que tomamos partes de Flanker que utilizaban módulos de Python o bases de datos específicos como Redis y dnspython, y los hicimos más modulares. Ahora puedes utilizar cualquier base de datos (o ninguna) para almacenar tus resultados en caché.

Esto significaba que primero teníamos que extraer el código, asegurarnos de que se pudiera consumir sin problemas, y después teníamos que volver a integrar Flanker de manera efectiva en Mailgun en su nueva forma. También aprovechamos la oportunidad para refactorizar gran parte del analizador de direcciones (ver punto 5 a continuación), lo que dificultó un poco más las cosas.

Podríamos haber hecho una bifurcación de nuestra base de código interna de Flanker, haber hecho todo lo posible por eliminar las dependencias y haber vuelto a usar lo que ya funcionaba internamente. Sin embargo, eso supondría descuidar el código abierto o tener que mantener dos bases de código diferentes. En su lugar, decidimos comprometernos a seguir utilizando el código abierto en producción.

Esto significa que, al combinar una solicitud de extracción (hemos hecho ocho desde que publicamos Flanker hace unas semanas y tenemos cuatro más pendientes), no solo tenemos que asegurarnos de que el código esté limpio, se pueda mantener y esté orientado al rendimiento, sino que también debemos comprobar que todos los cambios funcionen bien con el resto de Mailgun.

Como es de esperar, el análisis de direcciones y el análisis MIME son el núcleo de Mailgun. Como habíamos hecho grandes modificaciones en el proceso de publicación del código abierto, tuvimos que ser muy prudentes a la hora de volver a integrar el código en Mailgun para no romper las aplicaciones de nuestra clientela. Quizá no sea para tanto, pero lo sentimos un poco como hacer el spagat entre dos camiones marcha atrás.

Para lograrlo, fuimos implementando Flanker por fases. En primer lugar, comenzamos implementando Flanker para una pequeña porción de nuestro tráfico. Esto nos permitió empezar a detectar situaciones en las que el comportamiento del nuevo analizador de direcciones era más estricto que antes. Para ciertas cosas, como permitir caracteres de control en los nombres para mostrar, decidimos denegarlo, ya que supone un riesgo de seguridad. Para otras, como la asistencia de Unicode, decidimos tener la mayor flexibilidad posible a la hora de aceptarlo. Sí, eso significa que ahora puedes enviar el emoji de la caca como nombre para mostrar a través de Mailgun, y nosotros lo codificaremos correctamente y lo transmitiremos.

También pensamos que sería prudente ver si podíamos publicarlo como código abierto sin que nos despidieran. Flanker es una de las piezas fundamentales de Mailgun, así que tiene un gran valor para Rackspace. Aunque a veces creemos que es una buena estrategia pedir perdón en lugar de pedir permiso para avanzar con los proyectos, es probable que esta no fuera una de esas veces. Por lo tanto, se lo consultamos a los equipos legales y de producto de Rackspace para asegurarnos de que estuvieran de acuerdo. Por suerte, el eslogan de Rackspace es la “empresa de la nube abierta” y se dedica al software de código abierto. Por tanto, no fue difícil convencerles de que liberar Flanker como código abierto era lo correcto.

Llevábamos mucho tiempo ejecutando nuestro analizador MIME en producción, pero la parte del validador de emails (Guardpost) era relativamente nueva. Lanzamos Guardpost como una API antes de publicar Flanker como código abierto. Esto nos permitió realizar pruebas eficaces en condiciones reales antes del lanzamiento como código abierto.

A medida que Guardpost se popularizó, aunque lo ejecutábamos en un equipo dedicado bastante potente, empezó a tener problemas para gestionar el volumen de tráfico que recibía. Así que, dedicamos un tiempo a analizar el perfil de Guardpost para averiguar el motivo de la lentitud y resultó ser el corrector ortográfico. Dedicamos un tiempo a investigar cómo podíamos mejorarlo y acabamos por reescribirlo por completo. Puedes leer nuestro artículo del blog sobre cómo logramos que el corrector ortográfico fuera 135 veces más rápido que antes.

También pudimos solucionar un buen número de errores que la gente fue encontrando. Estos iban desde añadir asistencia en Internet Explorer para nuestra demostración de validación (nadie en el equipo tenía un equipo Windows, ¡así que tuvimos que comprar una licencia para solucionar ese error!) hasta enviar un email directamente a un dominio de nivel superior (TLD).

Ejecutar el código en producción antes de publicarlo como código abierto nos permitió tener seguridad y sentir orgullo por el código que estábamos liberando en el mercado.

Esto es muy importante. Cuando tienes una base de código interna en la que estás programando, puedes acercarte a la persona que la desarrolló y hacerle una pregunta rápida. Ese no es el caso del software de código abierto, así que queríamos asegurarnos de que Flanker estuviera bien documentado para que a la gente nueva le resultara fácil empezar a programar en él. Esto significa que Flanker tiene una buena documentación en el propio código a través de comentarios, además de documentación externa como un Guía de inicio rápido, Manual de usuario, y referencia de la API.

En definitiva, eso es lo que hemos aprendido al publicar Flanker como código abierto. Aunque acabó siendo mucho trabajo, fue un proceso liberador y esperamos recoger sus frutos en un futuro.

Nos encantaría conocer tus experiencias en la sección de comentarios de este artículo o en HackerNews.

El equipo de Mailgun

Autor: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!