[15/02/2023] Construir y gestionar la infraestructura uno mismo proporciona más control, pero el esfuerzo por mantenerlo todo bajo control puede restar recursos a la innovación en otras áreas. A Matt Doka, director de tecnología de FiveStars, una plataforma de marketing para pequeñas empresas, no le gusta esa compensación y hace todo lo posible por subcontratar todo lo que puede.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Lo demuestra en su reticencia a gestionar sus propios servidores, pero quizá sea más evidente en su actitud hacia la ingeniería de datos, donde se acerca al final de un viaje de cinco años para automatizar o externalizar gran parte del trabajo de mantenimiento mundano y centrar los recursos internos en el análisis de datos.
FiveStars ofrece a las pequeñas empresas un servicio de tarjetas de fidelización en línea -el equivalente digital de las tarjetas de sellos "compre nueve, llévese uno gratis"- que pueden vincular a los números de teléfono y las tarjetas de pago de sus clientes. Más de 10 mil pequeñas empresas utilizan sus servicios, y Doka calcula que unos 70 millones de estadounidenses han optado por los programas de fidelización que gestiona. Más recientemente, se ha introducido en el procesamiento de pagos, una opción adoptada por alrededor del 20% de sus clientes, y ofrece sus propios terminales de pago conformes con PCI.
El registro de todas esas interacciones genera una cantidad prodigiosa de datos, pero eso no es ni la mitad. Para superar a los procesadores de pagos tradicionales que se limitan a entregar un terminal y dejan que los clientes llamen al servicio de asistencia si deja de funcionar, FiveStars incorpora sistemas de telemetría a sus terminales, que informan periódicamente del estado de la conexión, el nivel de batería y el rendimiento de las aplicaciones.
"La mayor parte de nuestra carga ni siquiera son las transacciones, los puntos o las propias tarjetas de crédito", afirma. "Son las enormes cantidades de datos telemétricos de los dispositivos para asegurarnos de que, cuando alguien quiere hacer un pago o ganar puntos, la experiencia sea la mejor".
Para averiguar eso a partir de los datos se necesita mucho análisis, un trabajo para el que el equipo de datos de 10 personas tenía menos tiempo, ya que el simple mantenimiento de su infraestructura de datos se lo estaba comiendo todo.
El equipo de datos que creó la primera versión de la infraestructura de datos de FiveStars empezó en el departamento de ventas y marketing, no en el de TI. Ese accidente histórico significaba que, aunque conocían bien los datos, tenían poca experiencia en gestión de infraestructuras, señala Doka.
Cuando Doka se hizo cargo del equipo, descubrió que lo habían escrito todo a mano: el código de automatización del servidor, las consultas a la base de datos, los análisis... todo. "¡Escribían guiones bash!", comenta Doka. "Incluso hace 10 años, tenías sistemas que podían abstraer los scripts bash".
El sistema era frágil, muy manual y se basaba en muchos conocimientos tribales. El efecto neto era que los analistas de datos dedicaban la mayor parte de su tiempo a mantener el sistema en funcionamiento. "Luchaban por conseguir que las nuevas percepciones de datos se desarrollaran en análisis", anota.
En el 2019, añade, la respuesta de todo el mundo a un problema como ese era utilizar Apache Airflow, una plataforma de código abierto para gestionar flujos de trabajo de ingeniería de datos escrita y controlada con Python. Se desarrolló originalmente en AirBnB para realizar exactamente el tipo de cosas que el equipo de Doka todavía estaba haciendo a mano.
Doka optó por una versión alojada de Airflow para sustituir el sistema casero de FiveStars, que consumía muchos recursos. "Quería sacarnos del negocio de alojar nuestra propia infraestructura, porque estos son analistas de datos o incluso ingenieros de datos, no SREs experimentados", señala. "Tampoco es un buen uso de nuestro tiempo".
Adoptar Airflow significó que Doka podía dejar de preocuparse por otras cosas además de los servidores. "Hubo una gran mejora en la estandarización y los fundamentos de ejecutar las cosas", anota. "Simplemente heredas todas estas mejores prácticas que estábamos inventando o reinventando nosotros mismos".
Pero, se lamenta, "cómo se trabaja realmente en Airflow depende totalmente del equipo de desarrollo, por lo que todavía se gastan muchos ciclos mentales en la estructuración de cada nuevo proyecto". Y una de sus quejas particulares es que tiene que crear sus propias buenas prácticas de documentación.
Así que apenas un año después de comenzar la migración a Airflow, Doka se encontró buscando algo mejor para ayudarle a automatizar más de sus procesos de ingeniería de datos, y estandarizar algunas de las decisiones menos críticas para el negocio que le llevaban tanto tiempo.
Pero muchas de las herramientas que encontró solo abordaban una parte del problema.
"DBT solo se centraba en cómo cambiar los datos dentro de una única instancia de Snowflake, por ejemplo", sostiene. "Hace un trabajo realmente bueno en eso, pero ¿cómo se introducen los datos en Snowflake desde todas las fuentes?". Para eso, añade, "había algunas plataformas que podían abstraer todo el movimiento de datos de una manera estandarizada, como Fivetran, pero realmente no daban un lenguaje para procesar".
Después de comprobar otras opciones, Doka acabó decantándose por Ascend.io. "Me encantó el hecho de que hubiera una forma estándar de escribir una consulta SQL o código Python, y genera un linaje y una topología", comenta. "El sistema puede saber automáticamente de dónde proceden todos los datos; cómo han llegado hasta este análisis final".
Esto no solo elimina el reto de ejecutar servidores, sino también el de decidir cómo se hace el trabajo, agrega.
"Esto ahorra una tonelada de carga mental a los ingenieros y analistas de datos", afirma. "Son capaces de centrarse por completo en la pregunta que están tratando de responder y en el análisis que están tratando de hacer".
No solo es más fácil para los analistas centrarse en su propio trabajo, también es más fácil para ellos seguir el de los demás, añade.
"Hay toda esta documentación incorporada por diseño en la que, sin pensar en ello, cada analista deja un claro rastro de migas de cómo ha llegado hasta donde está", señala. "Así que, si nuevas personas se unen al proyecto, es más fácil ver lo que está pasando".
Ascend utiliza otro proyecto de Apache, Spark, como motor de análisis, y tiene su propia API de Python, PySpark.
La migración de los primeros casos de uso básicos desde Airflow llevó menos de un mes. "Se tardó una hora en encender, y dos minutos en conectar Postgres y algunas de nuestras fuentes de datos", comenta Doka. "Eso fue muy rápido".
Replicar algunos de los flujos de trabajo fue tan fácil como copiar el SQL subyacente de Airflow a Ascend. "Una vez que lo teníamos funcionando a la par, simplemente apagábamos el flujo [antiguo] y poníamos el conector de salida [nuevo] donde tenía que ir", señala.
Lo más útil de Ascend era que ejecutaba los cambios de código con tanta rapidez que el equipo podía desarrollar y corregir cosas en tiempo real. "El sistema puede ser consciente de si las piezas del flujo de trabajo han cambiado o no, y no lo vuelve a ejecutar todo si no ha cambiado nada, por lo que no se desperdicia computación", afirma. "Ha sido una gran mejora".
Sin embargo, algunas cosas seguían requiriendo una espera nocturna. "Hay un servicio ascendente del que solo se puede descargar entre las 2 y las 5 de la madrugada, así que conseguir que el código fuera el correcto, para asegurarnos de que se descargaba a la hora adecuada del día, fue un fastidio, pero no fue necesariamente culpa de Ascend", comenta.
Movilizar un cambio cultural
El cambio a Ascend tampoco supuso grandes necesidades de formación o contratación. "La construcción es prácticamente nula ahora que tenemos todo abstraído", afirma Doka, y ahora hay tres personas ejecutando trabajos en la parte superior de los nuevos sistemas, y alrededor de seis analistas haciendo informes y generando ideas a partir de los datos.
"La mayor parte del trabajo de infraestructura ha desaparecido", añade. Aún queda algo de trabajo ETL, la transformación y limpieza que nunca desaparece, pero ahora se hace de forma estandarizada. Sin embargo, algo que llevó tiempo digerir fue el cambio de lo que yo llamo Python vainilla utilizado con Airflow a Spark Python. Es diferente a escribir código procedimental". No se trata de conocimientos esotéricos, sino de algo que el equipo de FiveStars no había utilizado antes y con lo que necesitaba familiarizarse.
Un tema recurrente en el viaje de Doka por la ingeniería de datos ha sido la búsqueda de cosas nuevas que pueda dejar de construir y comprar en su lugar.
"Cuando construye, posee y gestiona una parte de la infraestructura en casa, tiene un mayor nivel de control y conocimiento", señala. "Pero a menudo sacrifica mucho tiempo por ello, y en muchos casos no tiene los mejores conocimientos para desarrollarla".
Convencer a sus colegas de las ventajas de hacer menos no fue fácil. "Luché con el equipo en ambas épocas", comenta. "Eso siempre forma parte de la transición a cualquier sistema más abstracto".
Doka dice que ha trabajado con varias startups como inversor o asesor, y siempre les dice a los fundadores con mentalidad técnica que eviten ejecutar la infraestructura ellos mismos y elijan un proveedor de la mejor clase para alojar las cosas por ellos, y no solo porque ahorra tiempo. "También aprenderá mucho mejor las mejores prácticas trabajando con ellos", afirma. Ofrece a los responsables de TI de las empresas el mismo consejo cuando tratan con equipos internos. "Lo más constante que he visto a lo largo de 11 años como CTO es que la gravedad simplemente tira de la gente para 'construirlo aquí' por alguna razón", sostiene. "Nunca lo he entendido". Es algo a lo que hay que resistirse continuamente o acabar perdiendo el tiempo manteniendo cosas que no forman parte del negocio principal.
Basado en el artículo de Peter Sayer (CIO) y editado por CIO Perú
Puede ver también: