Una revisión completa de la infraestructura es una de las iniciativas más desafiantes que emprende cualquier equipo de tecnología. Muchas veces, el equipo detrás de una pila en particular podría haber dejado el equipo, lo que provocó muchas circunstancias imprevistas. Sin embargo, ese no fue el caso en mPharma, a lo largo de los años tuvimos una transferencia de conocimiento adecuada a través de partes críticas del sistema. En este artículo, me gustaría compartir cómo logramos migrar nuestra infraestructura central de Marathon/Mesos a Kubernetes.

A lo largo de los años, hemos estado construyendo activamente una serie de productos basados ​​en las necesidades cada vez mayores de un paciente en África. Para enumerar algunos;

1. Escalamos con éxito Bloom , nuestra aplicación patentada para administrar la farmacia moderna en 9 países (al momento de escribir este artículo, ese número ha aumentado a 10).
2. También lanzamos myMutti , una plataforma de comercio electrónico para comprar medicamentos de venta libre (OTC) en línea y recibirlos en su hogar.
3. Creamos y lanzamos una aplicación de almacén y logística para realizar un mejor seguimiento del movimiento de productos desde nuestro almacén a las farmacias y hospitales asociados conocidos como Marketplace.
4. Lanzamos una aplicación de entrega de última milla para digitalizar aún más la forma en que transportamos medicamentos.
5. También comenzamos a recopilar datos de diagnóstico dentro de Bloom para aumentar nuestro programa de médicos múltiples .

Durante años, el equipo de ingeniería había estado contemplando la posibilidad de migrar nuestra infraestructura central. Sin embargo, nuestro crecimiento explosivo como empresa nos llevó a priorizar la construcción de productos en lugar de reinventar nuestra infraestructura central. En enero de 2021, nos dimos cuenta de que necesitamos reinventar nuestra infraestructura o, de lo contrario, no podremos respaldar el tipo de crecimiento que estábamos experimentando como empresa y equipo.

La infraestructura central de mPharma había pasado por diferentes fases a lo largo de los años; sin embargo, este fue nuestro primer intento de una revisión completa y también de garantizar que nuestra infraestructura coincidiera con el crecimiento de la empresa y el equipo en su conjunto.

Nuestras discusiones comenzaron centrándose en el problema que buscábamos resolver. Esto ayudó a garantizar que redujéramos cualquier elemento de sesgo al elegir una herramienta en particular y nos concentráramos en la mejor solución. Una pregunta clave que nos hicimos fue "¿qué stack nos ayudará a crecer?". Comenzamos centrándonos en cinco áreas clave;
1. Escalabilidad
2. Experiencia del desarrollador
3. Soporte de la comunidad
4. Seguridad
5. Costo

En base a lo anterior y algunos debates acalorados, optamos por Kubernetes.

¿Qué es Kubernetes?

Según Kubernetes.io , Kubernetes, también conocido como K8s, es un sistema de código abierto para automatizar la implementación, el escalado y la gestión de aplicaciones en contenedores. Agrupa los contenedores que componen una aplicación en unidades lógicas para facilitar la gestión y el descubrimiento. Kubernetes se basa en 15 años de experiencia ejecutando cargas de trabajo de producción en Google, combinado con las mejores ideas y prácticas de la comunidad.

Proceso de Migración

Cualquier migración de esta escala generalmente conduce a tiempos de inactividad del servicio, nuestro objetivo era eliminar esto por completo o minimizar su ocurrencia. Nuestro primer paso consistió en formar un equipo de proyecto dirigido por un líder de proyecto. El líder del proyecto fue responsable de manejar la gestión de extremo a extremo de la migración y garantizar que todas las partes interesadas pertinentes estuvieran al tanto del progreso de las diferentes iniciativas. Algunos de estos incluyen;
1. ¿Cuál será el costo adicional de activar servidores adicionales?
2. ¿Cuál es la mejor manera de implementar fácilmente aplicaciones en Kubernetes sin causar interrupciones en el flujo de trabajo de desarrollo?
3. ¿Cómo mediremos el éxito de la implementación?
4. ¿Cómo cambiaremos de manera eficiente el tráfico de nuestros servidores antiguos a los nuevos después de la migración?

¿Cuál será el costo adicional por activar servidores adicionales?

Como equipo, uno de nuestros enfoques clave es reducir los costos, ya que estos ahorros se traducen en que mPharma, como empresa, puede ofrecer medicamentos a costos más bajos a los pacientes. Nos dispusimos a hablar con nuestro proveedor de la nube para ver si tenían un programa para proyectos de prueba de concepto (POC). Logramos que nuestro proveedor de nube cubriera el costo de nuestra migración hasta que estuvimos en una posición estable. Básicamente, gastamos $0 en las primeras semanas de nuestra migración debido a esto.

¿Cuál es la mejor manera de implementar fácilmente aplicaciones en Kubernetes sin causar interrupciones en el flujo de trabajo de desarrollo?

Queríamos una forma de realizar esta migración sin interrumpir el ciclo de vida de desarrollo de software de los ingenieros. Una cosa clave a tener en cuenta es que durante la migración continuamos creando productos para pacientes y el negocio siguió creciendo a un ritmo alarmante. Antes de esta migración, todos nuestros servicios tenían un archivo .yaml que contenía instrucciones de implementación. No queríamos sobrecargar a los ingenieros con la redacción de un nuevo conjunto de instrucciones de implementación. Esto nos hizo decidir centralizar nuestro script de implementación en GitLab. Dentro de este script, teníamos secciones que implementaban código tanto en Marathon/Mesos como en Kubernetes. Esto aseguró que el trabajo de los ingenieros no se viera afectado durante este período de migración.

¿Cómo cambiaremos de manera eficiente el tráfico de nuestros servidores antiguos a los nuevos después de la migración?

Esta fue la etapa más delicada y difícil de nuestra estrategia de migración. Nuestro enfoque estaba en qué camino resultará en una interrupción en la calidad del servicio. Cambiar el tráfico a los nuevos servidores fue complicado para nosotros porque al hacer esta migración habíamos revisado cómo hacíamos la autenticación y la autorización. Esto hizo imposible para nosotros hacer una migración gradual. Tuvimos que migrar todos los servicios a la vez. Después de algunas discusiones, nos inclinamos por usar datos de tráfico para tomar esta decisión. Examinamos el tráfico de nuestras aplicaciones para decidir el mejor momento para realizar un cambio de tráfico. Después de mirar los datos de nuestra puerta de enlace API, nos decidimos el sábado por la noche. Esto se debió a que vimos menos tráfico en nuestra red los domingos, por lo que cualquier interrupción tendrá un radio de explosión muy pequeño. También optamos por trabajar desde la oficina para poder reducir la fricción en la comunicación. Pedimos mucha pizza, porque sabíamos que la tarea que teníamos entre manos no iba a ser fácil. A las 23:00 GMT, procedimos a hacer el cambio de tráfico.

¿Cómo mediremos el éxito de la implementación?

Uno de los equipos de los que se escucha poco es nuestro equipo de Garantía de calidad y SRE. Estos dos equipos se aseguran de que los productos que construimos cumplan con los más altos estándares. Sin embargo, como Isaac, el líder de control de calidad siempre dirá: "La calidad de los productos no es solo responsabilidad del equipo de control de calidad". Decidimos colaborar para probar diferentes partes de la aplicación después de la migración para asegurarnos de que todo funcionaba sin problemas. Otra área clave que no destaqué fue que, antes de la implementación en producción, migramos nuestros entornos de prueba y etapa a Kubernetes. Esto nos dio la confianza de que todo se probó correctamente y funcionó como se esperaba.

Lecciones aprendidas

1. No prestar atención a las métricas de uso

Poco después de la implementación en Kubernetes, notamos una serie de problemas informados por nuestros usuarios sobre tiempos de inactividad de la aplicación. Al migrar nuestras aplicaciones, nos enfocamos en medidas de reducción de costos, limitamos la cantidad de memoria y CPU que se puede asignar a un contenedor en particular. Esto llevó a que los contenedores murieran o se reiniciaran cada vez que alcanzaban un límite de memoria o CPU. Una lección clave para nosotros fue no prestar atención a las métricas de uso de contenedores de nuestra antigua infraestructura y usarlas para decidir cómo asignamos recursos a cada servicio.

2. Configuración incorrecta de los servicios por parte de los propietarios de los servicios

Otro error que notamos fueron configuraciones incorrectas por parte de los propietarios del servicio. Hubo mucho trabajo manual involucrado en la configuración de las variables de entorno para los servicios, lo que llevó a los ingenieros a cometer errores. Esto es algo en lo que estamos trabajando activamente y descubriendo la mejor manera de administrar las variables para limitar la cantidad de errores.

3. Falta de pruebas unitarias y de extremo a extremo

Debido a cómo manejamos la autenticación en nuestra antigua infraestructura y la necesidad de migrar lo antes posible, omitimos las pruebas unitarias y las pruebas de un extremo a otro en nuestra canalización de CI/CD. Esto condujo a varios errores que habrían sido detectados. En el caso de que hagamos otra migración, siempre nos aseguraremos de que esta etapa esté incluida en el proceso de CI/CD.

4. Cambio de tráfico:

Cambiar el tráfico entre nuestra infraestructura antigua y la nueva podría haberse manejado de manera diferente. En lugar de cambiar el 100 % del tráfico, podríamos habernos centrado en hacerlo de forma incremental para reducir el radio de explosión.

Se necesitaron alrededor de 6 meses para escribir este artículo, ya que el equipo se centró en garantizar que la migración no condujera a una degradación en la calidad del servicio y también se centró en crear/mejorar los productos con los que interactúan nuestros clientes. Diré que al interactuar con diferentes partes interesadas clave dentro y fuera del negocio, la migración fue un éxito. Continuamos mejorando nuestros servicios para brindar un mejor servicio a nuestros clientes y asegurarnos de facilitar que los pacientes se beneficien de la enorme inversión en infraestructura que mPharma está realizando en el cuidado de la salud.