Fundamentos de la Ingeniería de Datos

Capítulo 4. Elegir tecnologías a lo largo del ciclo de vida de la ingeniería de datos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

La ingeniería de datos sufre hoy en día un bochorno de riquezas. No nos faltan tecnologías para resolver diversos tipos de problemas de datos. Las tecnologías de datos están disponibles como ofertas llave en mano consumibles de casi todas las formas: código abierto, código abierto gestionado, software propietario, servicio propietario y más. Sin embargo, es fácil quedar atrapado en la persecución de la tecnología de vanguardia y perder de vista el objetivo central de la ingeniería de datos: diseñar sistemas robustos y fiables para transportar los datos a lo largo de todo su ciclo de vida y servirlos según las necesidades de los usuarios finales. Al igual que los ingenieros de estructuras eligen cuidadosamente las tecnologías y los materiales para hacer realidad la visión de un arquitecto para un edificio, los ingenieros de datos tienen la tarea de elegir la tecnología adecuada para conducir los datos a lo largo del ciclo de vida y servir a las aplicaciones y usuarios de datos.

El Capítulo 3 trató sobre la "buena" arquitectura de datos y por qué es importante. Ahora explicamos cómo elegir las tecnologías adecuadas al servicio de esta arquitectura. Los ingenieros de datos deben elegir buenas tecnologías para elaborar el mejor producto de datos posible. Creemos que el criterio para elegir una buena tecnología de datos es sencillo: ¿añade valor a un producto de datos y a la empresa en general?

A mucha gente confunde arquitectura y herramientas. La arquitectura es estratégica; las herramientas son tácticas. A veces oímos: "Nuestra arquitectura de datos son las herramientas X, Y y Z". Es una forma equivocada de pensar en la arquitectura. La arquitectura es el diseño de alto nivel, la hoja de ruta y el plano de los sistemas de datos que satisfacen los objetivos estratégicos de la empresa. La arquitectura es el qué, el por qué y el cuándo. Las herramientas se utilizan para hacer realidad la arquitectura; las herramientas son el cómo.

En vemos a menudo que los equipos se "descarrilan" y eligen tecnologías antes de trazar una arquitectura. Las razones varían: síndrome del objeto brillante, desarrollo impulsado por el currículum y falta de experiencia en arquitectura. En la práctica, esta priorización de la tecnología a menudo significa que improvisan una especie de máquina de fantasía del Dr. Seuss en lugar de una verdadera arquitectura de datos. Desaconsejamos encarecidamente elegir la tecnología antes de tener una arquitectura adecuada. La arquitectura primero, la tecnología después.

Este capítulo de trata de nuestro plan táctico para elegir la tecnología una vez que tengamos un anteproyecto de arquitectura estratégica. A continuación se exponen algunas consideraciones para elegir tecnologías de datos a lo largo del ciclo de vida de la ingeniería de datos:

• Tamaño y capacidades del equipo

• Rapidez de comercialización

• Interoperabilidad

• Optimización de costes y valor empresarial

• Hoy frente al futuro: tecnologías inmutables frente a transitorias

• Ubicación (nube, on prem, nube híbrida, multicloud)

• Construir frente a comprar

• Monolito frente a modular

• Sin servidor frente a los servidores

• Optimización, rendimiento y la guerra de los puntos de referencia

• El trasfondo del ciclo de vida de la ingeniería de datos

Tamaño y capacidades del equipo

La primera cosa que tienes que evaluar es el tamaño de tu equipo y sus capacidades con la tecnología. ¿Estás en un equipo pequeño (quizás un equipo de uno) de personas de las que se espera que lleven muchos sombreros, o el equipo es lo suficientemente grande como para que la gente trabaje en funciones especializadas? ¿Un puñado de personas será responsable de múltiples etapas del ciclo de vida de la ingeniería de datos, o la gente cubre nichos concretos? El tamaño de tu equipo influirá en los tipos de tecnologías que adoptes.

Existe un continuo de tecnologías simples a complejas, y el tamaño de un equipo determina aproximadamente la cantidad de ancho de banda que puede dedicar a soluciones complejas. A veces vemos que los equipos de datos pequeños leen entradas de blog sobre una nueva tecnología de perímetro en una empresa tecnológica gigante y luego intentan emular esas mismas tecnologías y prácticas extremadamente complejas. A esto lo llamamos ingeniería de culto a la carga, y suele ser un gran error que consume mucho tiempo y dinero valiosos, a menudo con poco o nada que mostrar a cambio. Especialmente en el caso de los equipos pequeños o con menos conocimientos técnicos, utiliza tantas herramientas gestionadas y SaaS como sea posible, y dedica tu limitado ancho de banda a resolver los problemas complejos que añaden valor directamente a la empresa.

Haz un inventario de las habilidades de tu equipo. ¿La gente se inclina por herramientas de bajo código, o prefieren enfoques de "primero el código"? ¿Son las personas fuertes en ciertos lenguajes como Java, Python o Go? Hay tecnologías disponibles para satisfacer todas las preferencias en el espectro del código bajo al código pesado. De nuevo, sugerimos ceñirse a tecnologías y flujos de trabajo con los que el equipo esté familiarizado. Hemos visto a equipos de datos invertir mucho tiempo en aprender la nueva y reluciente tecnología, lenguaje o herramienta de datos, sólo para no utilizarla nunca en producción. Aprender nuevas tecnologías, lenguajes y herramientas supone una inversión de tiempo considerable, así que haz estas inversiones con prudencia.

Velocidad de comercialización

En tecnología, gana la velocidad de comercialización. Esto significa elegir las tecnologías adecuadas que te ayuden a ofrecer funciones y datos más rápidamente, manteniendo al mismo tiempo unos estándares y una seguridad de alta calidad. También significa trabajar en un estrecho bucle de retroalimentación de lanzamiento, aprendizaje, iteración y realización de mejoras.

Lo perfecto es enemigo de lo bueno. Algunos equipos de datos deliberan sobre las opciones tecnológicas durante meses o años sin llegar a ninguna decisión. Las decisiones y los resultados lentos son el beso de la muerte para los equipos de datos. Hemos visto disolverse a más de un equipo de datos por ir demasiado despacio y no aportar el valor para el que fueron contratados.

Aporta valor pronto y a menudo. Como hemos mencionado, utiliza lo que funciona. Los miembros de tu equipo probablemente aprovecharán mejor las herramientas que ya conocen. Evita las tareas pesadas indiferenciadas que comprometen a tu equipo en un trabajo innecesariamente complejo que añade poco o ningún valor. Elige herramientas que te ayuden a avanzar de forma rápida, fiable, segura y protegida.

Interoperabilidad

Rara vez utilizarás una sola tecnología o sistema. Al elegir una tecnología o sistema, tendrás que asegurarte de que interactúa y funciona con otras tecnologías. La interoperabilidad describe cómo se conectan, intercambian información e interactúan diversas tecnologías o sistemas.

Supongamos que estás evaluando dos tecnologías, A y B. ¿Con qué facilidad se integra la tecnología A con la tecnología B cuando se piensa en la interoperabilidad? A menudo se trata de un espectro de dificultad, que va desde la integración sin fisuras a la que requiere mucho tiempo. ¿La integración perfecta ya está incorporada en cada producto, lo que facilita la configuración? ¿O tienes que hacer un montón de configuraciones manuales para integrar estas tecnologías?

A menudo, los proveedores y los proyectos de código abierto se dirigen a plataformas y sistemas específicos para interoperar. La mayoría de las herramientas de ingestión y visualización de datos tienen integraciones incorporadas con almacenes y lagos de datos populares. Además, las herramientas populares de ingestión de datos se integrarán con API y servicios comunes, como CRM, software de contabilidad, etc.

A veces existen estándares para la interoperabilidad. Casi todas las bases de datos permiten conexiones mediante Java Database Connectivity (JDBC) u Open Database Connectivity (ODBC), lo que significa que puedes conectarte fácilmente a una base de datos utilizando estas normas. En otros casos, la interoperabilidad se produce en ausencia de normas. La transferencia de estado representacional (REST) no es realmente una norma para las API; cada API REST tiene sus peculiaridades. En estos casos, depende del proveedor o del proyecto de software de código abierto (OSS) garantizar una integración fluida con otras tecnologías y sistemas.

Ten siempre presente lo sencillo que será conectar tus distintas tecnologías a lo largo del ciclo de vida de la ingeniería de datos. Como se ha mencionado en otros capítulos, te sugerimos que diseñes para la modularidad y te des la posibilidad de cambiar fácilmente de tecnología a medida que surjan nuevas prácticas y alternativas.

Optimización de costes y valor empresarial

En un mundo perfecto, podrías experimentar con todas las tecnologías más novedosas y geniales sin tener en cuenta el coste, la inversión de tiempo o el valor añadido a la empresa. En realidad, los presupuestos y el tiempo son finitos, y el coste es una limitación importante para elegir las arquitecturas y tecnologías de datos adecuadas. Tu organización espera un ROI positivo de tus proyectos de datos, por lo que debes comprender los costes básicos que puedes controlar. La tecnología es un importante factor de coste, por lo que tus elecciones tecnológicas y tus estrategias de gestión afectarán significativamente a tu presupuesto. Miramos los costes a través de tres lentes principales: coste total de propiedad, coste de oportunidad y FinOps.

Coste total de propiedad

El coste total de propiedad (CTP ) es el coste total estimado de una iniciativa, incluidos los costes directos e indirectos de los productos y servicios utilizados. Los costes directos pueden atribuirse directamente a una iniciativa. Algunos ejemplos son los salarios de un equipo que trabaja en la iniciativa o la factura de AWS por todos los servicios consumidos. Los costes indirectos, también conocidos como gastos generales, son independientes de la iniciativa y deben pagarse independientemente de su imputación.

Aparte de los gastos directos e indirectos, la forma en que se adquiere algo influye en el modo en que se contabilizan los gastos. Los gastos se dividen en dos grandes grupos: gastos de capital y gastos operativos.

Los gastos de capital, también conocido como capex, requieren una inversión inicial. Hoy se exige un pago. Antes de que existiera la nube, las empresas solían comprar hardware y software por adelantado mediante grandes contratos de adquisición. Además, se requerían importantes inversiones para alojar el hardware en salas de servidores, centros de datos e instalaciones de colocación. Estas inversiones iniciales -comúnmente de cientos de miles a millones de dólares o más- se trataban como activos y se amortizaban lentamente con el tiempo. Desde una perspectiva presupuestaria, se necesitaba capital para financiar toda la compra. Esto es capex, un importante desembolso de capital con un plan a largo plazo para conseguir un ROI positivo del esfuerzo y el gasto realizados.

Los gastos operativos, también conocidos como opex, son lo contrario del capex en ciertos aspectos. Los gastos operativos son graduales y se distribuyen a lo largo del tiempo. Mientras que el capex se centra en el largo plazo, el opex es a corto plazo. El opex puede ser de pago por uso o similar y permite mucha flexibilidad. El opex está más cerca de un coste directo, por lo que es más fácil atribuirlo a un proyecto de datos.

Hasta hace poco, el opex no era una opción para los grandes proyectos de datos. Los sistemas de datos a menudo requerían contratos multimillonarios. Esto ha cambiado con la llegada de la nube, ya que los servicios de plataformas de datos permiten a los ingenieros pagar según un modelo basado en el consumo. En general, el opex permite a los equipos de ingeniería una mayor capacidad para elegir su software y hardware. Los servicios basados en la nube permiten a los ingenieros de datos iterar rápidamente con diversas configuraciones de software y tecnología, a menudo a bajo coste.

Los ingenieros de datos deben ser pragmáticos en cuanto a la flexibilidad. El panorama de los datos está cambiando demasiado deprisa como para invertir en hardware a largo plazo que inevitablemente se queda obsoleto, no puede escalarse fácilmente y potencialmente obstaculiza la flexibilidad de un ingeniero de datos para probar cosas nuevas. Dadas las ventajas de la flexibilidad y los bajos costes iniciales, instamos a los ingenieros de datos a que adopten un enfoque centrado en la nube y las tecnologías flexibles de pago por uso.

Coste total de oportunidad de la propiedad

Cualquier elección excluye intrínsecamente otras posibilidades. El coste total de oportunidad de la propiedad (TOCO ) es el coste de las oportunidades perdidas en que incurrimos al elegir una tecnología, una arquitectura o un proceso.¹ Ten en cuenta que la propiedad en este entorno no requiere compras a largo plazo de hardware o licencias. Incluso en un entorno de nube, somos propietarios de una tecnología, una pila o una canalización una vez que se convierte en una parte esencial de nuestros procesos de producción de datos y es difícil abandonarla. Los ingenieros de datos a menudo no evalúan el TOCO cuando emprenden un nuevo proyecto; en nuestra opinión, se trata de un enorme punto ciego.

Si eliges la pila de datos A, habrás elegido las ventajas de la pila de datos A por encima de todas las demás opciones, excluyendo de hecho las pilas de datos B, C y D. Te comprometes con la pila de datos A y todo lo que conlleva: el equipo de apoyo, la formación, la configuración y el mantenimiento. ¿Qué ocurre si la pila de datos A fue una mala elección? ¿Qué ocurre cuando la pila de datos A se queda obsoleta? ¿Puedes pasar a otras pilas de datos?

¿Cómo de rápido y barato puedes pasar a algo más nuevo y mejor? Esta es una pregunta crítica en el espacio de los datos, donde las nuevas tecnologías y productos parecen aparecer a un ritmo cada vez más rápido. ¿La experiencia que has acumulado en la pila de datos A se traslada a la siguiente oleada? ¿O puedes cambiar componentes de la pila de datos A y ganar tiempo y opciones?

El primer paso para minimizar el coste de oportunidad es evaluarlo con los ojos bien abiertos. Hemos visto a innumerables equipos de datos quedarse atascados con tecnologías que parecían buenas en su momento y que, o bien no son flexibles para el crecimiento futuro, o simplemente están obsoletas. Las tecnologías de datos inflexibles se parecen mucho a las trampas para osos. Es fácil meterse en ellas y muy doloroso escapar.

FinOps

En ya abordamos las FinOps en el "Principio 9: Adoptar las FinOps". Como ya hemos comentado, el gasto típico en la nube es inherentemente opex: las empresas pagan por servicios para ejecutar procesos de datos críticos en lugar de hacer compras por adelantado y recuperar el valor con el tiempo. El objetivo de FinOps es hacer plenamente operativas la responsabilidad financiera y el valor empresarial aplicando prácticas similares a DevOps de monitorización y ajuste dinámico de los sistemas.

En este capítulo, queremos hacer hincapié en una cosa sobre las FinOps que queda bien plasmada en esta cita:²

Si parece que FinOps consiste en ahorrar dinero, piénsalo otra vez. FinOps consiste en ganar dinero. El gasto en la nube puede generar más ingresos, señalar el crecimiento de la base de clientes, permitir una mayor velocidad de lanzamiento de productos y funciones, o incluso ayudar a cerrar un centro de datos.

En nuestro entorno de ingeniería de datos, la capacidad de iterar rápidamente y escalar dinámicamente es inestimable para crear valor empresarial. Ésta es una de las principales motivaciones para trasladar las cargas de trabajo de datos a la nube.

Hoy frente al futuro: Tecnologías inmutables frente a transitorias

En un dominio tan apasionante como la ingeniería de datos, es demasiado fácil centrarse en un futuro que evoluciona rápidamente ignorando las necesidades concretas del presente. La intención de construir un futuro mejor es noble, pero a menudo conduce a un exceso de arquitectura e ingeniería. Las herramientas elegidas para el futuro pueden estar obsoletas y anticuadas cuando llegue ese futuro; el futuro a menudo se parece poco a lo que imaginamos años antes.

Como te dirían muchos entrenadores de vida, céntrate en el presente. Debes elegir la mejor tecnología para el momento y el futuro próximo, pero de forma que admita las incógnitas y la evolución futuras. Pregúntate: ¿dónde estás hoy y cuáles son tus objetivos para el futuro? Tus respuestas a estas preguntas deberían informar tus decisiones sobre tu arquitectura y, por tanto, sobre las tecnologías utilizadas dentro de esa arquitectura. Esto se consigue comprendiendo lo que es probable que cambie y lo que tiende a permanecer igual.

En tenemos que considerar dos clases de herramientas: las inmutables y las transitorias. Las tecnologías inmutables pueden ser componentes que sustentan la nube o lenguajes y paradigmas que han superado la prueba del tiempo. En la nube, ejemplos de tecnologías inmutables son el almacenamiento de objetos, las redes, los servidores y la seguridad. El almacenamiento de objetos, como Amazon S3 y Azure Blob Storage, existirá desde hoy hasta el final de la década, y probablemente mucho más. Almacenar tus datos en almacenamiento de objetos es una sabia elección. El almacenamiento de objetos sigue mejorando de diversas formas y ofrece constantemente nuevas opciones, pero tus datos estarán seguros y serán utilizables en el almacenamiento de objetos independientemente de la rápida evolución de la tecnología en su conjunto.

En cuanto a los lenguajes, SQL y bash existen desde hace muchas décadas, y no vemos que vayan a desaparecer pronto. Las tecnologías inmutables se benefician del efecto Lindy: cuanto más tiempo lleve establecida una tecnología, más tiempo se utilizará. Piensa en la red eléctrica, las bases de datos relacionales, el lenguaje de programación C o la arquitectura de procesadores x86. Sugerimos aplicar el efecto Lindy como prueba de fuego para determinar si una tecnología es potencialmente inmutable.

Las tecnologías transitorias son las que van y vienen. La trayectoria típica comienza con un gran despliegue publicitario, seguido de un crecimiento meteórico en popularidad, y luego un lento descenso a la oscuridad. El panorama de las interfaces de JavaScript es un ejemplo clásico. ¿Cuántos marcos frontales de JavaScript han aparecido y desaparecido entre 2010 y 2020? Backbone.js, Ember.js y Knockout eran populares a principios de la década de 2010, y React y Vue.js tienen una gran influencia en la actualidad. ¿Cuál será el marco JavaScript frontend más popular dentro de tres años? Quién sabe.

Cada día llegan al frente de los datos nuevos participantes bien financiados y proyectos de código abierto. Cada vendedor dirá que su producto cambiará la industria y "hará del mundo un lugar mejor". La mayoría de estas empresas y proyectos no consiguen tracción a largo plazo y se desvanecen lentamente en la oscuridad. Las grandes empresas de capital riesgo están haciendo grandes apuestas, sabiendo que la mayoría de sus inversiones en herramientas de datos fracasarán. Si las sociedades de capital riesgo que invierten millones (o miles de millones) en herramientas de datos no aciertan, ¿cómo puedes saber en qué tecnologías invertir para tu arquitectura de datos? Es difícil. No hay más que ver el número de tecnologías que aparecen en las (in)famosas descripciones de Matt Turck sobre el panorama del ML, la IA y los datos (MAD) que presentamos en el Capítulo 1(Figura 4-1).

Incluso las tecnologías de relativo éxito suelen caer rápidamente en la oscuridad, tras unos años de rápida adopción, víctimas de su éxito. Por ejemplo, a principios de la década de 2010, Hive tuvo una rápida acogida porque permitía tanto a analistas como a ingenieros consultar conjuntos de datos masivos sin codificar a mano complejos trabajos MapReduce. Inspirados por el éxito de Hive, pero deseando mejorar sus deficiencias, los ingenieros desarrollaron Presto y otras tecnologías. Hive aparece ahora principalmente en implementaciones heredadas. Casi todas las tecnologías siguen este inevitable camino de declive.

Figura 4-1. El panorama de datos de la MAD 2021 de Matt Turck

Nuestros consejos

Dada la rapidez con que cambian las herramientas y las buenas prácticas, sugerimos evaluar las herramientas cada dos años(Figura 4-2). Siempre que sea posible, encuentra las tecnologías inmutables a lo largo del ciclo de vida de la ingeniería de datos, y utilízalas como base. Construye herramientas transitorias en torno a las inmutables.

Figura 4-2. Utiliza un horizonte temporal de dos años para reevaluar tus opciones tecnológicas

Dada la razonable probabilidad de fracaso de muchas tecnologías de datos, debes considerar lo fácil que es la transición desde una tecnología elegida. ¿Cuáles son las barreras para abandonar? Como ya hemos mencionado en nuestro debate sobre el coste de oportunidad, evita las "trampas para osos". Entra en una nueva tecnología con los ojos bien abiertos, sabiendo que el proyecto puede abandonarse, que la empresa puede no ser viable o que la tecnología simplemente ya no encaja.

Ubicación

Las empresas tienen ahora numerosas opciones a la hora de decidir dónde ejecutar sus pilas tecnológicas. Un lento cambio hacia la nube culmina en una auténtica estampida de empresas que ponen en marcha cargas de trabajo en AWS, Azure y Google Cloud Platform (GCP). En la última década, muchos directores de tecnología han llegado a considerar que sus decisiones sobre el alojamiento tecnológico tienen una importancia existencial para sus organizaciones. Si se mueven con demasiada lentitud, corren el riesgo de quedar rezagados frente a su competencia más ágil; por otra parte, una migración a la nube mal planificada podría provocar un fracaso tecnológico y costes catastróficos.

Veamos los principales lugares para ejecutar tu pila tecnológica: en las instalaciones, la nube, la nube híbrida y la multicloud.

En las instalaciones

Mientras que las nuevas startups de nacen cada vez más en la nube, los sistemas locales siguen siendo la norma para las empresas establecidas. Básicamente, estas empresas son propietarias de su hardware, que puede vivir en centros de datos de su propiedad o en un espacio de colocación alquilado. En cualquier caso, las empresas son responsables operativamente de su hardware y del software que se ejecuta en él. Si el hardware falla, tienen que repararlo o sustituirlo. También tienen que gestionar los ciclos de actualización cada pocos años, a medida que se lanza nuevo hardware actualizado y el antiguo envejece y se vuelve menos fiable. Deben asegurarse de que tienen suficiente hardware para hacer frente a los picos; para un minorista online, esto significa alojar suficiente capacidad para hacer frente a los picos de carga del Viernes Negro. Para los ingenieros de datos a cargo de los sistemas locales, esto significa comprar sistemas lo suficientemente grandes como para permitir un buen rendimiento para los picos de carga y los grandes trabajos sin comprar ni gastar en exceso.

Por un lado, las empresas consolidadas han establecido prácticas operativas que les han servido bien. Supongamos que una empresa que depende de las tecnologías de la información lleva algún tiempo en el mercado. Esto significa que ha conseguido hacer malabarismos con los costes y las necesidades de personal para hacer funcionar su hardware, gestionar los entornos de software, implementar el código de los equipos de desarrollo y hacer funcionar las bases de datos y los sistemas de big data.

Por otro lado, las empresas establecidas ven que su competencia más joven y ágil escala rápidamente y aprovecha los servicios gestionados en la nube. También ven que los competidores establecidos hacen incursiones en la nube, lo que les permite escalar temporalmente una enorme potencia informática para trabajos de datos masivos o el pico de compras del Viernes Negro.

Las empresas de sectores competitivos no suelen tener la opción de quedarse quietas. La competencia es feroz, y siempre existe la amenaza de verse "perturbadas" por una competencia más ágil, a menudo respaldada por un gran montón de dólares de capital riesgo. Todas las empresas deben mantener sus sistemas existentes en funcionamiento de forma eficiente mientras deciden qué pasos dar a continuación. Esto podría implicar la adopción de nuevas prácticas DevOps, como contenedores, Kubernetes, microservicios e implementación continua, manteniendo al mismo tiempo su hardware en funcionamiento en las instalaciones. Podría implicar una migración completa a la nube, como se explica a continuación.

Nube

La nube da la vuelta al modelo local. En lugar de comprar hardware, simplemente alquilas hardware y servicios gestionados a un proveedor de la nube (como AWS, Azure o Google Cloud). Estos recursos pueden reservarse a menudo a muy corto plazo; las máquinas virtuales se ponen en marcha en menos de un minuto, y el uso posterior se factura en incrementos por segundo. Esto permite a los usuarios de la nube escalar dinámicamente recursos que eran inconcebibles con servidores locales.

En un entorno de nube, los ingenieros pueden lanzar rápidamente proyectos y experimentar sin preocuparse de la planificación de hardware a largo plazo. Pueden empezar a ejecutar servidores en cuanto su código esté listo para la implementación. Esto hace que el modelo de la nube resulte extremadamente atractivo para las startups que andan justas de presupuesto y tiempo.

La primera era de la nube estuvo dominada por las ofertas de infraestructura como servicio (IaaS) -productos como máquinas virtuales y discos virtuales que son esencialmente trozos de hardware alquilados-. Poco a poco, hemos visto un cambio hacia plataforma como servicio (PaaS), mientras que los productos SaaS siguen creciendo a un ritmo rápido.

PaaS incluye productos IaaS, pero añade servicios gestionados más sofisticados para dar soporte a las aplicaciones. Algunos ejemplos son bases de datos gestionadas como Amazon Relational Database Service (RDS) y Google Cloud SQL, plataformas de streaming gestionadas como Amazon Kinesis y Simple Queue Service (SQS), y Kubernetes gestionados como Google Kubernetes Engine (GKE) y Azure Kubernetes Service (AKS). Los servicios PaaS permiten a los ingenieros ignorar los detalles operativos de la gestión de máquinas individuales y la implementación de marcos en sistemas distribuidos. Proporcionan acceso llave en mano a sistemas complejos y autoescalables con una sobrecarga operativa mínima.

Las ofertas SaaS suben un peldaño más en la escala de abstracción. El SaaS suele proporcionar una plataforma de software empresarial totalmente funcional con poca gestión operativa. Algunos ejemplos de SaaS son Salesforce, Google Workspace, Microsoft 365, Zoom y Fivetran. Tanto las principales nubes públicas como terceros ofrecen plataformas SaaS. El SaaS abarca todo un espectro de ámbitos empresariales, como videoconferencias, gestión de datos, tecnología publicitaria, aplicaciones de oficina y sistemas CRM.

En este capítulo también se habla de los productos sin servidor, cada vez más importantes en las ofertas PaaS y SaaS. Los productos sin servidor suelen ofrecer escalado automatizado desde cero hasta tasas de uso extremadamente altas. Se facturan sobre la base del pago por uso y permiten a los ingenieros operar sin conocimiento operativo de los servidores subyacentes. Mucha gente discute el término "sin servidor"; al fin y al cabo, el código debe ejecutarse en algún sitio. En la práctica, sin servidor suele significar muchos servidores invisibles.

Los servicios en la nube son cada vez más atractivos para las empresas establecidas con centros de datos e infraestructuras informáticas existentes. El escalado dinámico y sin fisuras es muy valioso para las empresas que se enfrentan a la estacionalidad (por ejemplo, las empresas minoristas que hacen frente a la carga del Viernes Negro) y a los picos de carga del tráfico web. El advenimiento de la COVID-19 en 2020 fue uno de los principales impulsores de la adopción de la nube, ya que las empresas reconocieron el valor de escalar rápidamente los procesos de datos para obtener información en un clima empresarial muy incierto; las empresas también tuvieron que hacer frente a un aumento sustancial de la carga debido a un pico en las compras en línea, el uso de aplicaciones web y el trabajo a distancia.

Antes de discutir los matices de la elección de tecnologías en la nube, vamos a discutir primero por qué la migración a la nube requiere un cambio drástico de pensamiento, específicamente en el frente de la fijación de precios; esto está estrechamente relacionado con FinOps, introducido en "FinOps". Las empresas que migran a la nube suelen cometer importantes errores de implementación al no adaptar adecuadamente sus prácticas al modelo de precios de la nube.

Un breve desvío sobre la economía de las nubes

Para entender cómo utilizar eficazmente los servicios en la nube mediante una arquitectura nativa de la nube, necesitas saber cómo ganan dinero las nubes. Se trata de un concepto extremadamente complejo y sobre el que los proveedores de nubes ofrecen poca transparencia. Considera esta barra lateral como un punto de partida para tu investigación, descubrimiento y desarrollo de procesos.

Servicios en la nube y Credit Default Swaps

Salgamos por una pequeña tangente sobre las permutas de riesgo de crédito. No te preocupes, esto tendrá sentido dentro de un rato. Recordemos que las permutas de cobertura por impago saltaron a la fama tras la crisis financiera mundial de 2007. Un swap de incumplimiento crediticio era un mecanismo para vender diferentes niveles de riesgo vinculados a un activo (por ejemplo, una hipoteca). No es nuestra intención presentar esta idea en detalle, sino más bien ofrecer una analogía en la que muchos servicios en la nube son similares a los derivados financieros; los proveedores de la nube no sólo dividen los activos de hardware en pequeñas piezas mediante la virtualización, sino que también venden estas piezas con diferentes características técnicas y riesgos asociados. Aunque los proveedores son extremadamente herméticos sobre los detalles de sus sistemas internos, existen enormes oportunidades de optimización y escalado mediante la comprensión de los precios de la nube y el intercambio de notas con otros usuarios.

Mira el ejemplo del almacenamiento de archivo en la nube. En el momento de escribir esto, GCP admite abiertamente que su almacenamiento de clase archivo funciona en los mismos clusters que el almacenamiento estándar en la nube, y sin embargo el precio por gigabyte al mes del almacenamiento de archivo es aproximadamente 1/17 el del almacenamiento estándar. ¿Cómo es posible?

He aquí nuestra conjetura. Al comprar almacenamiento en la nube, cada disco de un clúster de almacenamiento tiene tres activos que utilizan los proveedores y consumidores de la nube. En primer lugar, tiene una determinada capacidad de almacenamiento, digamos 10 TB. En segundo lugar, admite un determinado número de operaciones de entrada/salida (IOP) por segundo -digamos, 100-. En tercer lugar, los discos admiten un determinado ancho de banda máximo, la velocidad máxima de lectura de archivos organizados de forma óptima. Un disco magnético puede ser capaz de leer a 200 MB/s.

Cualquiera de estos límites (IOPs, capacidad de almacenamiento, ancho de banda) es un cuello de botella potencial para un proveedor de la nube. Por ejemplo, el proveedor de la nube puede tener un disco que almacena 3 TB de datos pero que alcanza el máximo de IOPs. Una alternativa a dejar vacíos los 7 TB restantes es vender el espacio vacío sin vender IOPs. O, más concretamente, vender espacio de almacenamiento barato e IOP caras para desincentivar las lecturas.

Al igual que los comerciantes de derivados financieros, los vendedores de nubes también negocian con el riesgo. En el caso del almacenamiento de archivos, los vendedores están vendiendo un tipo de seguro, pero uno que paga la aseguradora y no el comprador de la póliza en caso de catástrofe. Aunque los costes mensuales de almacenamiento de datos son extremadamente baratos, me arriesgo a pagar un precio elevado si alguna vez necesito recuperar datos. Pero es un precio que pagaré gustosamente en caso de verdadera emergencia.

Consideraciones similares se aplican a casi cualquier servicio en la nube. Mientras que los servidores locales se venden esencialmente como hardware básico, el modelo de costes en la nube es más sutil. En lugar de limitarse a cobrar por los núcleos de la CPU, la memoria y las funciones, los proveedores de la nube monetizan características como la durabilidad, la fiabilidad, la longevidad y la previsibilidad; diversas plataformas informáticas descuentan sus ofertas para cargas de trabajo que son efímeras o que pueden interrumpirse arbitrariamente cuando se necesita capacidad en otro lugar.

En la nube ≠ In situ

Este encabezamiento de puede parecer una tautología tonta, pero la creencia de que los servicios en la nube son iguales que los conocidos servidores locales es un error cognitivo muy extendido que plaga las migraciones a la nube y da lugar a facturas espantosas. Esto demuestra un problema más amplio en tecnología al que nos referimos como la maldición de la familiaridad. Muchos productos tecnológicos nuevos se diseñan intencionadamente para que parezcan algo familiar para facilitar su uso y acelerar su adopción. Pero cualquier producto tecnológico nuevo tiene sutilezas y arrugas que los usuarios deben aprender a identificar, acomodar y optimizar.

Trasladar uno a uno los servidores locales de a máquinas virtuales en la nube -lo que se conoce como simple "levantar y cambiar"- esuna estrategia perfectamente razonable para la fase inicial de la migración a la nube, especialmente cuando una empresa se enfrenta a algún tipo de precipicio financiero, como la necesidad de firmar un nuevo contrato de arrendamiento o de hardware importante si no se cierra el hardware existente. Sin embargo, a las empresas que dejan sus activos en la nube en este estado inicial les espera un duro golpe. En comparación directa, los servidores de larga duración en la nube son significativamente más caros que sus homólogos locales.

La clave para encontrar valor en la nube es comprender y optimizar el modelo de precios de la nube. En lugar de desplegar un conjunto de servidores de larga duración capaces de gestionar todos los picos de carga, utiliza el autoescalado para permitir que las cargas de trabajo escalen hasta una infraestructura mínima cuando las cargas sean ligeras y hasta clusters masivos durante los picos. Para obtener descuentos mediante cargas de trabajo más efímeras y menos duraderas, utiliza instancias reservadas o puntuales, o utiliza funciones sin servidor en lugar de servidores.

A menudo pensamos que esta optimización conduce a la reducción de costes, pero también deberíamos esforzarnos por aumentar el valor empresarial explotando la naturaleza dinámica de la nube.³ Los ingenieros de datos pueden crear nuevo valor en la nube logrando cosas que eran imposibles en su entorno local. Por ejemplo, es posible crear rápidamente clústeres informáticos masivos para ejecutar transformaciones complejas a escalas que eran inasequibles para el hardware local.

Gravedad de los datos

Además de errores básicos como seguir en la nube las prácticas operativas locales, los ingenieros de datos deben vigilar otros aspectos de los precios e incentivos de la nube que suelen pillar desprevenidos a los usuarios.

Los proveedores quieren encerrarte en sus ofertas. Introducir datos en la plataforma es barato o gratuito en la mayoría de las plataformas en la nube, pero sacarlos puede ser extremadamente caro. Ten en cuenta las tarifas de salida de datos y su impacto a largo plazo en tu empresa antes de que te sorprenda una factura elevada. La gravedad de los datos es real: una vez que los datos aterrizan en una nube, el coste de extraerlos y migrar los procesos puede ser muy elevado.

Nube híbrida

A medida que empresas más consolidadas migran a la nube, el modelo de nube híbrida adquiere cada vez más importancia. Prácticamente ninguna empresa puede migrar todas sus cargas de trabajo de la noche a la mañana. El modelo de nube híbrida asume que una organización mantendrá indefinidamente algunas cargas de trabajo fuera de la nube.

Hay muchas razones para plantearse un modelo de nube híbrida. Las organizaciones pueden creer que han alcanzado la excelencia operativa en determinadas áreas, como su pila de aplicaciones y el hardware asociado. Así, pueden migrar sólo a cargas de trabajo específicas en las que vean beneficios inmediatos en el entorno de la nube. Por ejemplo, una pila Spark local se migra a clústeres efímeros en la nube, lo que reduce la carga operativa de la gestión del software y el hardware para el equipo de ingeniería de datos y permite un rápido escalado para grandes trabajos de datos.

Este patrón de poner la analítica en la nube es hermoso porque los datos fluyen principalmente en una dirección, minimizando los costes de salida de datos(Figura 4-3). Es decir, las aplicaciones locales generan datos de eventos que pueden enviarse a la nube prácticamente gratis. El grueso de los datos permanece en la nube, donde se analiza, mientras que cantidades menores de datos se devuelven a las instalaciones para la implementación de modelos en aplicaciones, ETL inverso, etc.

Figura 4-3. Un modelo de flujo de datos en la nube híbrida que minimiza los costes de salida

Una nueva generación de ofertas de servicios gestionados de nube híbrida también permite a los clientes ubicar servidores gestionados por la nube en sus centros de datos.⁴ Esto ofrece a los usuarios la posibilidad de incorporar las mejores prestaciones de cada nube junto con la infraestructura local.

Multicloud

Multicloud simplemente se refiere a la implementación de cargas de trabajo en varias nubes públicas. Las empresas pueden tener varias motivaciones para las implementaciones multicloud. Las plataformas SaaS a menudo desean ofrecer servicios cercanos a las cargas de trabajo en la nube existentes de los clientes. Snowflake y Databricks proporcionan sus ofertas SaaS a través de múltiples nubes por este motivo. Esto es especialmente crítico para las aplicaciones intensivas en datos, donde la latencia de la red y las limitaciones de ancho de banda dificultan el rendimiento, y los costes de salida de datos de pueden ser prohibitivos.

Otra motivación común para emplear un enfoque multicloud es aprovechar los mejores servicios a través de varias nubes. Por ejemplo, una empresa puede querer gestionar sus datos de Google Ads y Analytics en Google Cloud e implementar Kubernetes a través de GKE. Y la empresa también podría adoptar Azure específicamente para las cargas de trabajo de Microsoft. Además, a la empresa le puede gustar AWS porque tiene varios servicios de primera clase (por ejemplo, AWS Lambda) y disfruta de una gran mentalidad, lo que hace relativamente fácil contratar ingenieros competentes en AWS. Cualquier combinación de varios servicios de proveedores de la nube es posible. Dada la intensa competencia entre los principales proveedores de la nube, es de esperar que ofrezcan más servicios de primera clase, lo que hará que la multicloud sea más atractiva.

Una metodología multicloud tiene varias desventajas. Como acabamos de mencionar, los costes de salida de datos y los cuellos de botella de las redes son críticos. Pasarse a la multicloud puede introducir una complejidad significativa. Las empresas deben gestionar ahora una vertiginosa gama de servicios en varias nubes; la integración entre nubes y la seguridad suponen un reto considerable; las redes multicloud pueden ser diabólicamente complicadas.

Una nueva generación de servicios de "nube de nubes" pretende facilitar la multicloud con una complejidad reducida, ofreciendo servicios a través de las nubes y replicando sin problemas los datos entre nubes o gestionando cargas de trabajo en varias nubes a través de un único panel de vidrio. Por citar un ejemplo, una cuenta Snowflake se ejecuta en una única región de nube, pero los clientes pueden crear fácilmente otras cuentas en GCP, AWS o Azure. Snowflake proporciona una sencilla replicación programada de datos entre estas diversas cuentas en la nube. La interfaz de Snowflake es esencialmente la misma en todas estas cuentas, lo que elimina la carga de formación que supone cambiar entre servicios de datos nativos de la nube.

El espacio de la "nube de nubes" está evolucionando rápidamente; dentro de unos años desde la publicación de este libro, habrá muchos más de estos servicios disponibles. Los ingenieros y arquitectos de datos harían bien en mantenerse al tanto de este panorama de nubes en rápida evolución.

Descentralizado: Blockchain y el perímetro

Aunque no se utiliza mucho ahora, merece la pena mencionar brevemente una nueva tendencia que podría popularizarse en la próxima década: la informática descentralizada. Mientras que las aplicaciones actuales se ejecutan principalmente en locales y en la nube, el auge del blockchain, la Web 3.0 y la computación de perímetro pueden invertir este paradigma. Por el momento, las plataformas descentralizadas han demostrado ser extremadamente populares, pero no han tenido un impacto significativo en el espacio de los datos; aun así, vale la pena estar atento a estas plataformas cuando evalúes las decisiones tecnológicas.

Nuestros consejos

Desde nuestra perspectiva, aún estamos al principio de la transición a la nube. Por tanto, las pruebas y argumentos en torno a la colocación y migración de cargas de trabajo están en proceso de cambio. La propia nube está cambiando, con un cambio del modelo IaaS construido en torno a Amazon EC2 que impulsó el crecimiento inicial de AWS y, de forma más general, hacia ofertas de servicios más gestionados como AWS Glue, Google BigQuery y Snowflake.

También hemos visto la aparición de nuevas abstracciones de colocación de cargas de trabajo. Los servicios locales se están volviendo más parecidos a la nube y más abstractos. Los servicios de nube híbrida permiten a los clientes ejecutar servicios totalmente gestionados dentro de sus muros, al tiempo que facilitan una estrecha integración entre los entornos locales y remotos. Además, la "nube de nubes" está empezando a tomar forma, impulsada por servicios de terceros y proveedores de nubes públicas.

Elige tecnologías para el presente, pero mira hacia el futuro

Como mencionamos en "Hoy frente al futuro: Tecnologías inmutables frente a transitorias", tienes que mantener un ojo en el presente mientras planificas para lo desconocido. Ahora mismo es un momento difícil para planificar colocaciones y migraciones de cargas de trabajo. Debido al rápido ritmo de competencia y cambio en el sector de la nube, el espacio de decisión tendrá un aspecto muy diferente dentro de cinco o diez años. Resulta tentador tener en cuenta todas las posibles permutaciones futuras de la arquitectura.

Creemos que es fundamental evitar esta trampa interminable del análisis. En lugar de eso, planifica el presente. Elige las mejores tecnologías para tus necesidades actuales y planes concretos para el futuro próximo. Elige tu plataforma de implementación basándote en las necesidades reales de tu empresa, al tiempo que te centras en la sencillez y la flexibilidad.

En particular, no elijas una estrategia compleja de nubes múltiples o híbridas a menos que haya una razón de peso. ¿Necesitas servir datos cerca de los clientes en varias nubes? ¿Te obligan las normativas del sector a albergar determinados datos en tus centros de datos? ¿Tienes una necesidad tecnológica imperiosa de servicios específicos en dos nubes diferentes? Elige una estrategia de implementación en una sola nube si estos escenarios no se dan en tu caso.

Por otro lado, ten un plan de escape. Como hemos subrayado antes, toda tecnología -incluso el software de código abierto- conlleva cierto grado de dependencia. Una estrategia de nube única tiene importantes ventajas de simplicidad e integración, pero conlleva un importante bloqueo. En este caso, estamos hablando de flexibilidad mental, la flexibilidad para evaluar el estado actual del mundo e imaginar alternativas. En el mejor de los casos, tu plan de escape permanecerá encerrado tras un cristal, pero prepararlo te ayudará a tomar mejores decisiones en el presente y te dará una salida si las cosas van mal en el futuro.

Argumentos de repatriación de la nube

Como escribimos este libro, Sarah Wang y Martin Casado publicaron "El coste de la nube, una paradoja de un billón de dólares", un artículo que generó mucho ruido y furia en el espacio tecnológico. Los lectores interpretaron ampliamente el artículo como una llamada a la repatriación de las cargas de trabajo de la nube a los servidores locales. Argumentan de forma algo más sutil que las empresas deberían dedicar importantes recursos a controlar el gasto en la nube y deberían considerar la repatriación como una posible opción.

Queremos dedicar un momento a diseccionar una parte de su debate. Wang y Casado citan la repatriación por parte de Dropbox de importantes cargas de trabajo de AWS a servidores propiedad de Dropbox como un caso de estudio para las empresas que estén considerando movimientos de repatriación similares.

No eres Dropbox, ni eres Cloudflare

Nosotros creemos que este caso práctico se utiliza con frecuencia sin el contexto adecuado y es un ejemplo convincente de la falacia lógica de la falsa equivalencia. Dropbox presta servicios concretos en los que la propiedad del hardware y los centros de datos puede ofrecer una ventaja competitiva. Las empresas no deberían basarse excesivamente en el ejemplo de Dropbox a la hora de evaluar las opciones de implementación en la nube y en las instalaciones.

En primer lugar, es importante comprender que Dropbox almacena enormes cantidades de datos. La empresa no dice exactamente cuántos datos aloja, pero afirma que son muchos exabytes y que siguen creciendo.

En segundo lugar, Dropbox gestiona una enorme cantidad de tráfico de red. Sabemos que su consumo de ancho de banda en 2017 fue lo suficientemente importante como para que la empresa añadiera "cientos de gigabits de conectividad a Internet con proveedores de tránsito (ISP regionales y globales), y cientos de nuevos socios de peering (donde intercambiamos tráfico directamente en lugar de a través de un ISP)".⁵ Los costes de salida de datos serían extremadamente elevados en un entorno de nube pública.

En tercer lugar, Dropbox es esencialmente un proveedor de almacenamiento en la nube, pero con un producto de almacenamiento altamente especializado que combina características de almacenamiento de objetos y de bloques. La competencia principal de Dropbox es un sistema diferencial de actualización de archivos que puede sincronizar eficazmente archivos editados activamente entre usuarios, minimizando al mismo tiempo el uso de la red y de la CPU. El producto no encaja bien con el almacenamiento de objetos, el almacenamiento de bloques u otras ofertas estándar en la nube. En cambio, Dropbox se ha beneficiado de la creación de una pila de software y hardware personalizada y altamente integrada.⁶

En cuarto lugar, mientras Dropbox trasladaba su producto principal a su hardware, siguió creando otras cargas de trabajo de AWS. Esto permite a Dropbox centrarse en construir un servicio en la nube altamente ajustado a una escala extraordinaria, en lugar de intentar sustituir varios servicios. Dropbox puede centrarse en su competencia principal de almacenamiento en la nube y sincronización de datos, mientras descarga la gestión de software y hardware en otras áreas, como el análisis de datos.⁷

Otras historias de éxito citadas con frecuencia que las empresas han construido fuera de la nube son Backblaze y Cloudflare, pero éstas ofrecen lecciones similares. Backblaze empezó como un producto de copia de seguridad de datos personales en la nube, pero desde entonces ha empezado a ofrecer B2, un servicio de almacenamiento de objetos similar a Amazon S3. Backblaze almacena actualmente más de un exabyte de datos. Cloudflare afirma prestar servicios a más de 25 millones de propiedades de Internet, con puntos de presencia en más de 200 ciudades y 51 terabits por segundo (Tbps) de capacidad total de red.

Netflix ofrece otro ejemplo útil. La empresa es famosa por ejecutar su pila tecnológica en AWS, pero esto sólo es cierto en parte. Netflix ejecuta la transcodificación de vídeo en AWS, lo que representa aproximadamente el 70% de sus necesidades informáticas en 2017.⁸ Netflix también ejecuta su backend de aplicaciones y análisis de datos en AWS. Sin embargo, en lugar de utilizar la red de distribución de contenidos de AWS, Netflix ha construido una CDN personalizada en colaboración con proveedores de servicios de Internet, utilizando una combinación altamente especializada de software y hardware. Para una empresa que consume una parte sustancial de todo el tráfico de Internet,⁹ la construcción de esta infraestructura crítica le permitió ofrecer vídeo de alta calidad a una enorme base de clientes de forma rentable.

Estos casos prácticos sugieren que tiene sentido que las empresas gestionen su propio hardware y conexiones de red en determinadas circunstancias. Los mayores éxitos modernos de empresas que construyen y mantienen hardware implican una escala extraordinaria (exabytes de datos, terabits por segundo de ancho de banda, etc.) y casos de uso limitados en los que las empresas pueden obtener una ventaja competitiva diseñando pilas de hardware y software altamente integradas. Además, todas estas empresas consumen un enorme ancho de banda de red, lo que sugiere que las tarifas de salida de datos serían un coste importante si optaran por operar totalmente desde una nube pública.

Considera seguir ejecutando las cargas de trabajo en las instalaciones o repatriar las cargas de trabajo en la nube si ejecutas un servicio verdaderamente a escala de la nube. ¿Qué es la escala de la nube? Puedes estar a escala de nube si almacenas un exabyte de datos o gestionas terabits por segundo de tráfico hacia y desde Internet. (Alcanzar un terabit por segundo de tráfico de red interno es bastante fácil.) Además, considera la posibilidad de ser propietario de tus servidores si los costes de salida de datos son un factor importante para tu empresa. Para dar un ejemplo concreto de cargas de trabajo a escala de la nube que podrían beneficiarse de la repatriación, Apple podría obtener una importante ventaja financiera y de rendimiento migrando el almacenamiento de iCloud a sus propios servidores.¹⁰

Construir frente a comprar

Construir o comprar es un viejo debate tecnológico. El argumento a favor de la construcción es que tienes el control total de la solución y no estás a merced de un proveedor o de una comunidad de código abierto. El argumento a favor de la compra se reduce a las limitaciones de recursos y la experiencia: ¿tienes la experiencia necesaria para crear una solución mejor que la que ya está disponible? Cualquiera de las dos decisiones se reduce al coste total de propiedad, al coste total de propiedad y a si la solución proporciona una ventaja competitiva a tu organización.

Si has captado un tema del libro hasta ahora, es que sugerimos invertir en construir y personalizar cuando hacerlo suponga una ventaja competitiva para tu empresa. De lo contrario, súbete a hombros de gigantes y utiliza lo que ya está disponible en el mercado. Dada la cantidad de servicios de código abierto y de pago -ambos pueden tener comunidades de voluntarios o equipos muy bien pagados de ingenieros increíbles-, es una tontería que lo construyas todo tú mismo.

Como preguntamos a menudo: "Cuando necesitas neumáticos nuevos para tu coche, ¿consigues la materia prima, creas los neumáticos desde cero y los instalas tú mismo?". Como la mayoría de la gente, probablemente compres neumáticos y hagas que alguien los instale. El mismo argumento se aplica a construir frente a comprar. Hemos visto equipos que han creado sus bases de datos desde cero. Un simple RDBMS de código abierto habría servido mucho mejor a sus necesidades tras un examen más detallado. Imagina la cantidad de tiempo y dinero invertidos en esta base de datos casera. Hablando de bajo ROI por TCO y coste de oportunidad.

Aquí es donde resulta útil la distinción entre el ingeniero de datos de tipo A y el de tipo B. Como hemos señalado antes, las funciones de tipo A y de tipo B suelen estar encarnadas en el mismo ingeniero, sobre todo en una organización pequeña. Siempre que sea posible, inclínate por el comportamiento de tipo A; evita el trabajo pesado indiferenciado y adopta la abstracción. Utiliza marcos de trabajo de código abierto o, si esto te supone demasiados problemas, estudia la posibilidad de comprar una solución gestionada o propietaria adecuada. En ambos casos, hay muchos servicios modulares excelentes entre los que elegir.

Merece la pena mencionar la realidad cambiante de sobre el modo en que las empresas adoptan el software. Mientras que en el pasado, el departamento de TI tomaba la mayoría de las decisiones de compra y adopción de software de forma descendente, en la actualidad, la tendencia es que la adopción de software en una empresa sea ascendente, impulsada por desarrolladores, ingenieros de datos, científicos de datos y otras funciones técnicas. La adopción de tecnología en las empresas se está convirtiendo en un proceso orgánico y continuo.

Veamos algunas opciones de soluciones de código abierto y propietarias.

Software de código abierto

El software de código abierto (OSS) es un modelo de distribución de software en el que el software, y la base de código subyacente, se ponen a disposición para uso general, normalmente bajo condiciones de licencia específicas. A menudo, el OSS es creado y mantenido por un equipo distribuido de colaboradores. El OSS es libre de usar, cambiar y distribuir la mayoría de las veces, pero con advertencias específicas. Por ejemplo, muchas licencias exigen que se incluya el código fuente del software derivado del código abierto cuando se distribuye el software.

Las motivaciones para crear y mantener OSS varían. A veces el OSS es orgánico, y surge de la mente de un individuo o de un pequeño equipo que crea una solución novedosa y decide liberarla para uso público. Otras veces, una empresa puede poner a disposición del público una herramienta o tecnología específica bajo una licencia de OSS.

El OSS tiene dos sabores principales: OSS gestionado por la comunidad y OSS comercial.

OSS gestionado por la comunidad

Los proyectos de OSS tienen éxito con una comunidad fuerte y una base de usuarios vibrante. El OSS gestionado por la comunidad es una vía predominante para los proyectos de OSS. La comunidad abre altas tasas de innovaciones y contribuciones de desarrolladores de todo el mundo con proyectos OSS populares.

Los siguientes son factores a tener en cuenta en un proyecto de OSS gestionado por la comunidad:

Mindshare

Evita adoptar proyectos OSS que no tengan tracción y popularidad. Fíjate en el número de estrellas de GitHub, las bifurcaciones y el volumen y la frecuencia de commits. Otra cosa a la que debes prestar atención es la actividad de la comunidad en los grupos de chat y foros relacionados. ¿Tiene el proyecto un fuerte sentido de comunidad? Una comunidad fuerte crea un círculo virtuoso de fuerte adopción. También significa que te resultará más fácil obtener asistencia técnica y encontrar talento cualificado para trabajar con el marco.

Madurez

¿Cuánto tiempo lleva existiendo el proyecto, cómo de activo es actualmente y cómo de útil lo encuentra la gente en la producción? La madurez de un proyecto indica que la gente lo encuentra útil y está dispuesta a incorporarlo a sus flujos de trabajo de producción.

Solución de problemas

¿Cómo tendrás que gestionar los problemas si surgen? ¿Estarás solo para solucionar los problemas, o podrá ayudarte la comunidad a resolverlos?

Gestión de proyectos

Fíjate en los problemas Git y en la forma en que se abordan. ¿Se resuelven rápidamente? Si es así, ¿cuál es el proceso para enviar una incidencia y conseguir que se resuelva?

Equipo

¿Hay alguna empresa que patrocine el proyecto OSS? ¿Quiénes son los colaboradores principales?

Relaciones con los promotores y gestión de la comunidad

¿Qué hace el proyecto para fomentar la adopción? ¿Existe una vibrante comunidad de chat (por ejemplo, en Slack) que proporcione ánimo y apoyo?

Contribuyendo

¿El proyecto fomenta y acepta pull requests? ¿Cuál es el proceso y los plazos para que las pull requests sean aceptadas e incluidas en la base de código principal?

Mapa de carreteras

¿Existe una hoja de ruta del proyecto? En caso afirmativo, ¿es clara y transparente?

Autoalojamiento y mantenimiento

¿Tienes recursos para alojar y mantener la solución de OSS? Si es así, ¿cuál es el TCO y el TOCO frente a la compra de un servicio gestionado al proveedor de OSS?

Retribuir a la comunidad

Si te gusta el proyecto y lo utilizas activamente, considera la posibilidad de invertir en él. Puedes contribuir al código base, ayudar a solucionar problemas y dar consejos en los foros y chats de la comunidad. Si el proyecto permite donaciones, considera hacer una. Muchos proyectos OSS son esencialmente proyectos de servicio a la comunidad, y los mantenedores suelen tener trabajos a tiempo completo además de ayudar con el proyecto OSS. Lamentablemente, a menudo es una labor de amor que no permite al mantenedor tener un salario digno. Si puedes permitirte hacer una donación, hazlo.

OSS comercial

A veces OSS tiene algunos inconvenientes. A saber, tienes que alojar y mantener la solución en tu entorno. Esto puede ser trivial o extremadamente complicado y engorroso, dependiendo de la aplicación OSS. Los proveedores comerciales intentan resolver este quebradero de cabeza de gestión alojando y gestionando la solución de OSS por ti, normalmente como una oferta SaaS en la nube. Ejemplos de estos proveedores son Databricks (Spark), Confluent (Kafka), DBT Labs (dbt), y hay muchos, muchos otros.

Este modelo se denomina OSS comercial (COSS). Normalmente, un proveedor ofrecerá el "núcleo" del OSS de forma gratuita, mientras que cobrará por las mejoras, las distribuciones de código curado o los servicios totalmente gestionados.

Un vendedor suele estar afiliado al proyecto comunitario de OSS. A medida que un proyecto de OSS se hace más popular, los mantenedores pueden crear una empresa separada para una versión gestionada del OSS. Esto suele convertirse en una plataforma SaaS en la nube construida en torno a una versión gestionada del código fuente abierto. Se trata de una tendencia muy extendida: un proyecto de OSS se hace popular, una empresa afiliada recauda grandes cantidades de capital riesgo para comercializar el proyecto de OSS, y la empresa crece como un cohete espacial.

En este punto, el ingeniero de datos tiene dos opciones. Puede seguir utilizando la versión OSS gestionada por la comunidad, que deberá seguir manteniendo por su cuenta (actualizaciones, mantenimiento del servidor/contenedor, pull requests para la corrección de errores, etc.). O puedes pagar al proveedor y dejar que se encargue de la gestión administrativa del producto COSS.

Los siguientes son factores a tener en cuenta en un proyecto comercial de OSS:

Valor

¿Ofrece el proveedor un valor mejor que si gestionaras tú mismo la tecnología OSS? Algunos proveedores añaden a sus ofertas gestionadas muchos extras que no están disponibles en la versión OSS comunitaria. ¿Te convencen estos añadidos?

Modelo de entrega

¿Cómo se accede al servicio? ¿El producto está disponible mediante descarga, API o interfaz web/móvil? Asegúrate de que puedes acceder fácilmente a la versión inicial y a las posteriores.

Ayuda

No se puede subestimar el soporte, y a menudo es opaco para el comprador. ¿Cuál es el modelo de asistencia del producto y tiene algún coste adicional? Con frecuencia, los vendedores venden soporte por una tarifa adicional. Asegúrate de que entiendes claramente los costes de obtener soporte. Comprende también qué cubre el soporte y qué no. Todo lo que no esté cubierto por el soporte será tu responsabilidad poseerlo y gestionarlo.

Lanzamientos y correcciones de errores

¿Es transparente el proveedor en cuanto al calendario de lanzamientos, mejoras y correcciones de errores? ¿Puedes acceder fácilmente a estas actualizaciones?

Ciclo de ventas y precios

A menudo, un proveedor ofrecerá precios bajo demanda, especialmente para un producto SaaS, y te ofrecerá un descuento si te comprometes a un acuerdo ampliado. Asegúrate de entender las ventajas y desventajas de pagar sobre la marcha o pagar por adelantado. ¿Merece la pena pagar un tanto alzado, o es mejor invertir tu dinero en otra cosa?

Finanzas de la empresa

¿Es viable la empresa? Si la empresa ha recaudado fondos de capital riesgo, puedes comprobar su financiación en sitios como Crunchbase. ¿Cuánto recorrido tiene la empresa? ¿Seguirá funcionando dentro de un par de años?

Logotipos frente a ingresos

¿Está la empresa centrada en hacer crecer el número de clientes (logos), o intenta hacer crecer los ingresos? Puede que te sorprenda el número de empresas preocupadas principalmente por aumentar su número de clientes, sus estrellas de GitHub o su número de miembros en el canal Slack, sin los ingresos necesarios para establecer unas finanzas sólidas.

Apoyo comunitario

¿Apoya realmente la empresa la versión comunitaria del proyecto OSS? ¿En qué medida contribuye la empresa a la base de código OSS de la comunidad? Han surgido polémicas con algunos proveedores que han cooptado proyectos de OSS y posteriormente han aportado poco valor a la comunidad. ¿Qué probabilidades hay de que el producto siga siendo viable como código abierto apoyado por la comunidad si la empresa cierra?

Ten en cuenta también que las nubes ofrecen sus propios productos de código abierto gestionados. Si un proveedor de nubes ve tracción con un producto o proyecto concreto, espera que ese proveedor ofrezca su versión. Esto puede ir desde ejemplos sencillos (Linux de código abierto ofrecido en máquinas virtuales) hasta servicios gestionados extremadamente complejos (Kafka totalmente gestionado). La motivación de estas ofertas es sencilla: las nubes ganan dinero a través del consumo. Un mayor número de ofertas en un ecosistema de nube significa una mayor probabilidad de "adhesión" y un aumento del gasto de los clientes.

Jardines amurallados privados

Aunque el OSS de está omnipresente, también existe un gran mercado para las tecnologías que no son OSS. Algunas de las mayores empresas de la industria de datos venden productos de código cerrado. Veamos dos tipos principales de jardines amurallados propietarios: las empresas independientes y las ofertas de plataformas en la nube.

Ofertas independientes

El panorama de las herramientas de datos de ha experimentado un crecimiento exponencial en los últimos años. Cada día surgen nuevas ofertas independientes de herramientas de datos. Con la capacidad de recaudar fondos de sociedades de capital riesgo, estas empresas de datos pueden escalar y contratar grandes equipos de ingeniería, ventas y marketing. Esto presenta una situación en la que los usuarios tienen algunas grandes opciones de productos en el mercado, mientras que tienen que vadear a través de un interminable desorden de ventas y marketing. En el momento de escribir esto, los buenos tiempos del capital libremente disponible para las empresas de datos están llegando a su fin, pero esa es otra larga historia cuyas consecuencias aún se están desarrollando.

A menudo, una empresa que vende una herramienta de datos no la publicará como OSS, sino que ofrecerá una solución propietaria. Aunque no tendrás la transparencia de una solución OSS pura, una solución propietaria independiente puede funcionar bastante bien, especialmente como servicio totalmente gestionado en la nube.

Las siguientes son cosas a tener en cuenta con una oferta independiente:

Interoperabilidad

Asegúrate de que la herramienta interopera con otras herramientas que hayas elegido (OSS, otras independientes, ofertas en la nube, etc.). La interoperabilidad es clave, así que asegúrate de que puedes probarla antes de comprarla.

Mindshare y cuota de mercado

¿Es popular la solución? ¿Está presente en el mercado? ¿Goza de opiniones positivas de los clientes?

Documentación y apoyo

Es inevitable que surjan problemas y preguntas. ¿Está claro cómo resolver tu problema, ya sea a través de la documentación o del soporte técnico?

Precios

¿Es comprensible el precio? Traza escenarios de uso de baja, media y alta probabilidad, con sus respectivos costes. ¿Eres capaz de negociar un contrato, junto con un descuento? ¿Merece la pena? ¿Cuánta flexibilidad pierdes si firmas un contrato, tanto en la negociación como en la capacidad de probar nuevas opciones? ¿Eres capaz de obtener compromisos contractuales sobre precios futuros?

Longevidad

¿Sobrevivirá la empresa el tiempo suficiente para que obtengas valor de su producto? Si la empresa ha recaudado dinero, busca información sobre su situación financiera. Mira las opiniones de los usuarios. Pregunta a tus amigos y publica preguntas en las redes sociales sobre las experiencias de los usuarios con el producto. Asegúrate de que sabes en qué te estás metiendo.

Ofertas de servicios propios de la plataforma en nube

Los proveedores de la nube desarrollan y venden sus propios servicios de almacenamiento, bases de datos y otros. Muchas de estas soluciones son herramientas internas utilizadas por las respectivas empresas hermanas. Por ejemplo, Amazon creó la base de datos DynamoDB para superar las limitaciones de las bases de datos relacionales tradicionales y gestionar las grandes cantidades de datos de usuarios y pedidos a medida que Amazon.com se convertía en un monstruo. Más tarde, Amazon ofreció el servicio DynamoDB únicamente en AWS; ahora es un producto de primera categoría utilizado por empresas de todos los tamaños y niveles de madurez. Los proveedores de nubes suelen agrupar sus productos para que funcionen bien juntos. Cada nube puede crear adherencia con su base de usuarios creando un ecosistema integrado fuerte.

Los siguientes son factores a tener en cuenta con una oferta de nube propia:

Comparaciones de rendimiento y precio

¿Es la oferta de la nube sustancialmente mejor que una versión independiente u OSS? ¿Cuál es el coste total de propiedad de elegir una oferta de nube?

Consideraciones sobre la compra

Los precios a la carta pueden ser caros. ¿Puedes reducir el coste comprando capacidad reservada o suscribiendo un acuerdo de compromiso a largo plazo?

Nuestros consejos

Construir frente a comprar vuelve a saber cuál es tu ventaja competitiva y dónde tiene sentido invertir recursos en la personalización. En general, favorecemos el OSS y el COSS por defecto, lo que te libera para centrarte en mejorar aquellas áreas en las que estas opciones son insuficientes. Céntrate en unas pocas áreas en las que construir algo añadirá un valor significativo o reducirá sustancialmente la fricción.

No consideres los gastos operativos internos como un coste irrecuperable. Hay un valor excelente en mejorar la cualificación de tu equipo de datos existente para crear sistemas sofisticados en plataformas gestionadas, en lugar de cuidar servidores locales. Además, piensa en cómo gana dinero una empresa, especialmente sus equipos de ventas y experiencia del cliente, que generalmente indicarán cómo te tratan durante el ciclo de ventas y cuando eres un cliente de pago.

Por último, ¿quién es el responsable del presupuesto en tu empresa? ¿Cómo decide esta persona los proyectos y tecnologías que se financian? Antes de plantear el caso empresarial para COSS o servicios gestionados, ¿tiene sentido intentar utilizar primero OSS? Lo último que quieres es que tu elección tecnológica se quede en el limbo mientras esperas la aprobación del presupuesto. Como dice el viejo refrán, el tiempo mata los tratos. En tu caso, cuanto más tiempo pases en el limbo, más probabilidades tendrás de que muera la aprobación de tu presupuesto. Conoce de antemano quién controla el presupuesto y qué se aprobará con éxito.

Monolito frente a modular

Monolitos frente a los sistemas modulares es otro viejo debate en el espacio de la arquitectura del software. Los sistemas monolíticos son autónomos, y a menudo realizan múltiples funciones en un único sistema. Los partidarios de los monolitos prefieren la simplicidad de tenerlo todo en el mismo sitio. Es más fácil razonar sobre una única entidad, y puedes avanzar más rápido porque hay menos piezas móviles. El bando modular se inclina por las tecnologías desacopladas, las mejores de su clase, que realizan tareas para las que son excepcionalmente buenas. Especialmente teniendo en cuenta el ritmo de cambio de los productos en el mundo de los datos, el argumento es que debes aspirar a la interoperabilidad entre un conjunto de soluciones en constante evolución.

¿Qué enfoque debes adoptar en tu pila de ingeniería de datos? Exploremos las compensaciones.

Monolito

El monolito(Figura 4-4) ha sido un pilar tecnológico durante décadas. Los viejos tiempos de la cascada significaban que las versiones de software eran enormes, estaban estrechamente acopladas y se movían con una cadencia lenta. Grandes equipos trabajaban juntos para entregar una única base de código funcional. Los sistemas de datos monolíticos continúan hoy en día, con proveedores de software antiguos como Informatica y marcos de código abierto como Spark.

Los pros del monolito son que es fácil razonar sobre él, y requiere una menor carga cognitiva y cambio de contexto, ya que todo es autocontenido. En lugar de tratar con docenas de tecnologías, tratas con "una" tecnología y, normalmente, con un lenguaje de programación principal. Los monolitos son una opción excelente si quieres simplicidad en el razonamiento sobre tu arquitectura y procesos.

Figura 4-4. El monolito acopla estrechamente sus servicios

Por supuesto, el monolito tiene sus contras. Para empezar, los monolitos son frágiles. Debido al gran número de piezas móviles, las actualizaciones y lanzamientos tardan más y tienden a cocerse en "el fregadero de la cocina". Si el sistema tiene un fallo -¡esperemos que el software se haya probado a fondo antes de su lanzamiento!- puede dañar todo el sistema.

Los problemas inducidos por el usuario también ocurren con los monolitos. Por ejemplo, vimos una tubería ETL monolítica que tardaba 48 horas en ejecutarse. Si algo se rompía en algún punto de la tubería, había que reiniciar todo el proceso. Mientras tanto, los ansiosos usuarios empresariales esperaban sus informes, que ya llevaban dos días de retraso por defecto y solían llegar mucho más tarde. Las averías eran lo bastante frecuentes como para que el sistema monolítico acabara desechándose.

La multitenencia en un sistema monolítico también puede ser un problema importante. Puede resultar difícil aislar las cargas de trabajo de varios usuarios. En un almacén de datos on-prem, una función definida por el usuario puede consumir suficiente CPU como para ralentizar el sistema para otros usuarios. Los conflictos entre dependencias y la contención de recursos son fuentes frecuentes de quebraderos de cabeza.

Otro contra de los monolitos es que cambiar a un nuevo sistema será doloroso si el proveedor o el proyecto de código abierto muere. Como todos tus procesos están contenidos en el monolito, salir de ese sistema y pasar a una nueva plataforma será costoso en tiempo y dinero.

Modularidad

La modularidad(Figura 4-5) es un concepto antiguo en ingeniería de software, pero los sistemas modulares distribuidos se pusieron verdaderamente de moda con el auge de los microservicios. En lugar de confiar en un monolito masivo para gestionar tus necesidades, ¿por qué no dividir los sistemas y procesos en sus propias áreas de interés? Los microservicios pueden comunicarse a través de API, lo que permite a los desarrolladores centrarse en sus dominios mientras hacen que sus aplicaciones sean accesibles a otros microservicios. Esta es la tendencia en ingeniería de software y se ve cada vez más en los sistemas de datos modernos.

Figura 4-5. Con la modularidad, cada servicio está desacoplado de otro

Las grandes empresas tecnológicas han sido impulsoras clave del movimiento de los microservicios. El famoso mandato API de Bezos disminuye el acoplamiento entre aplicaciones, permitiendo la refactorización y la descomposición. Bezos también impuso la regla de las dos pizzas (ningún equipo debe ser tan grande que dos pizzas no puedan alimentar a todo el grupo). Efectivamente, esto significa que un equipo tendrá como máximo cinco miembros. Este límite también limita la complejidad del ámbito de responsabilidad de un equipo, en concreto, la base de código que puede gestionar. Mientras que una aplicación monolítica extensa podría implicar un grupo de cien personas, dividir a los desarrolladores en pequeños grupos de cinco requiere que esta aplicación se divida en piezas pequeñas, manejables y débilmente acopladas.

En un entorno modular de microservicios, los componentes son intercambiables, y es posible crear una aplicación políglota (multilenguaje de programación); un servicio Java puede sustituir a un servicio escrito en Python. Los clientes de servicios sólo tienen que preocuparse de las especificaciones técnicas de la API del servicio, no de los detalles entre bastidores de la implementación.

Las tecnologías de procesamiento de datos han cambiado hacia un modelo modular, proporcionando un fuerte apoyo a la interoperabilidad. Los datos se guardan en un almacenamiento de objetos en un formato estándar, como Parquet, en lagos de datos y lakehouses. Cualquier herramienta de procesamiento compatible con el formato puede leer los datos y volver a escribir los resultados procesados en el lago para que los procese otra herramienta. Los almacenes de datos en la nube admiten la interoperabilidad con el almacenamiento de objetos mediante la importación/exportación utilizando formatos estándar y tablas externas, es decir, las consultas se ejecutan directamente en los datos de un lago de datos.

Las nuevas tecnologías llegan a escena a un ritmo vertiginoso en el ecosistema de datos actual, y la mayoría se quedan obsoletas y anticuadas rápidamente. Aclarar y repetir. La capacidad de intercambiar herramientas a medida que cambia la tecnología tiene un valor incalculable. Consideramos que la modularidad de los datos es un paradigma más poderoso que la ingeniería de datos monolítica. La modularidad permite a los ingenieros elegir la mejor tecnología para cada trabajo o paso del proceso.

Los contras de la modularidad son que hay más cosas sobre las que razonar. En lugar de manejar un único sistema de interés, ahora tienes potencialmente innumerables sistemas que comprender y manejar. La interoperabilidad es un posible quebradero de cabeza; esperemos que todos estos sistemas funcionen bien juntos.

Este mismo problema nos llevó a separar la orquestación como una corriente subterránea independiente, en lugar de colocarla bajo la gestión de datos. La orquestación también es importante para las arquitecturas de datos monolíticas; prueba de ello es el éxito de herramientas como Control-M de BMC Software en el espacio tradicional del almacenamiento de datos. Pero orquestar cinco o diez herramientas es mucho más complejo que orquestar una. La orquestación se convierte en el pegamento que une los módulos de la pila de datos.

El patrón de monolito distribuido

El patrón de monolito distribuido es una arquitectura distribuida que aún adolece de muchas de las limitaciones de la arquitectura monolítica. La idea básica es que se ejecuta un sistema distribuido con diferentes servicios para realizar diferentes tareas. Aún así, los servicios y los nodos comparten un conjunto común de dependencias o una base de código común.

Un ejemplo estándar es un clúster Hadoop tradicional. Un clúster Hadoop puede albergar simultáneamente varios frameworks, como Hive, Pig o Spark. El clúster también tiene muchas dependencias internas. Además, el clúster ejecuta componentes centrales de Hadoop: bibliotecas comunes de Hadoop, HDFS, YARN y Java. En la práctica, un clúster suele tener instalada una versión de cada componente.

Un sistema Hadoop estándar on-prem implica gestionar un entorno común que funcione para todos los usuarios y todos los trabajos. Gestionar las actualizaciones y las instalaciones es un reto importante. Obligar a los trabajos a actualizar sus dependencias corre el riesgo de romperlas; mantener dos versiones de un marco de trabajo conlleva una complejidad adicional.

Algunas tecnologías modernas de orquestación basadas en Python -por ejemplo, Apache Airflow- también adolecen de este problema. Aunque utilizan una arquitectura altamente desacoplada y asíncrona, cada servicio ejecuta el mismo código base con las mismas dependencias. Cualquier ejecutor puede ejecutar cualquier tarea, por lo que una biblioteca cliente para una única tarea ejecutada en un DAG debe instalarse en todo el clúster. Orquestar muchas herramientas implica instalar bibliotecas cliente para una gran cantidad de APIs. Los conflictos de dependencias son un problema constante.

Una solución a los problemas del monolito distribuido es la infraestructura efímera en un entorno de nube. Cada trabajo obtiene su propio servidor temporal o clúster instalado con dependencias. Cada clúster sigue siendo altamente monolítico, pero la separación de los trabajos reduce drásticamente los conflictos. Por ejemplo, este patrón es ahora bastante común para Spark con servicios como Amazon EMR y Google Cloud Dataproc.

Una segunda solución es descomponer adecuadamente el monolito distribuido en múltiples entornos de software utilizando contenedores. Tenemos más que decir sobre los contenedores en "Sin servidor frente a los servidores".

Nuestros consejos

Aunque los monolitos de son atractivos por su facilidad de comprensión y su reducida complejidad, esto tiene un alto coste. El coste es la pérdida potencial de flexibilidad, el coste de oportunidad y los ciclos de desarrollo de alta fricción.

He aquí algunas cosas que debes tener en cuenta al evaluar los monolitos frente a las opciones modulares:

Interoperabilidad

Arquitecto para compartir e interoperar.

Evitar la "trampa del oso

Algo en lo que es fácil entrar puede ser doloroso o imposible escapar.

Flexibilidad

Las cosas se mueven muy deprisa en el espacio de los datos ahora mismo. Comprometerse con un monolito reduce la flexibilidad y las decisiones reversibles.

Sin servidor frente a los servidores

Una gran tendencia para los proveedores de la nube es la tecnología sin servidor, que permite a los desarrolladores e ingenieros de datos ejecutar aplicaciones sin gestionar servidores entre bastidores. La tecnología sin servidor ofrece una rápida generación de valor para los casos de uso adecuados. Para otros casos, puede que no sea una buena opción. Veamos cómo evaluar si la tecnología sin servidor es adecuada para ti.

Sin servidor

Aunque serverless existe desde hace bastante tiempo, la tendencia serverless arrancó con fuerza con AWS Lambda en 2014. Con la promesa de ejecutar pequeños fragmentos de código según las necesidades, sin tener que gestionar un servidor, la popularidad de la tecnología sin servidor se disparó. Las principales razones de su popularidad son el coste y la comodidad. En lugar de pagar el coste de un servidor, ¿por qué no pagar simplemente cuando se evoca tu código?

Sin servidor tiene muchos sabores. Aunque la función como servicio (FaaS) es muy popular, los sistemas sin servidor son anteriores a la llegada de AWS Lambda. Por ejemplo, BigQuery de Google Cloud es sin servidor en el sentido de que los ingenieros de datos no necesitan gestionar la infraestructura de backend, y el sistema se escala a cero y se escala automáticamente para gestionar grandes consultas. Sólo tienes que cargar datos en el sistema y empezar a consultar. Pagas por la cantidad de datos que consume tu consulta y un pequeño coste por almacenar tus datos. Este modelo de pago -pagar por el consumo y el almacenamiento- es cada vez más frecuente.

¿Cuándo tiene sentido la tecnología sin servidor? Como ocurre con muchos otros servicios en la nube, depende; y los ingenieros de datos harían bien en comprender los detalles de los precios en la nube para predecir cuándo resultarán caras las implementaciones sin servidor. Si nos fijamos específicamente en el caso de AWS Lambda, varios ingenieros han encontrado trucos para ejecutar cargas de trabajo por lotes a un coste ínfimo.¹¹ Por otra parte, las funciones sin servidor adolecen de una ineficiencia inherente a la sobrecarga. Manejar un evento por llamada a la función a una tasa de eventos alta puede ser catastróficamente caro, especialmente cuando enfoques más sencillos como el multihilo o el multiprocesamiento son grandes alternativas.

Al igual que en otras áreas de operaciones, es fundamental monitorear y modelar. Monitoriza para determinar el coste por evento en un entorno real y la duración máxima de la ejecución sin servidor, y modela utilizando este coste por evento para determinar los costes generales a medida que aumenta el número de eventos. La modelización también debe incluir los peores escenarios: ¿qué ocurre si mi sitio es atacado por un enjambre de bots o un ataque DDoS?

Contenedores

En junto con los microservicios y los servicios sin servidor, los contenedores son una de las tecnologías operativas de tendencia más potentes en el momento de escribir estas líneas. Los contenedores desempeñan un papel tanto en los microservicios como en los servicios sin servidor.

Los contenedores suelen denominarse máquinas virtuales ligeras. Mientras que una máquina virtual tradicional envuelve todo un sistema operativo, un contenedor empaqueta un espacio de usuario aislado (como un sistema de archivos y unos pocos procesos); muchos de estos contenedores pueden coexistir en un único sistema operativo anfitrión. Esto proporciona algunas de las principales ventajas de la virtualización (es decir, el aislamiento de dependencias y código) sin la sobrecarga de transportar todo un núcleo de sistema operativo.

Un único nodo de hardware puede alojar numerosos contenedores con asignaciones de recursos de grano fino. En el momento de escribir esto, los contenedores siguen ganando popularidad, junto con Kubernetes, un sistema de gestión de contenedores. Los entornos sin servidor suelen ejecutarse en contenedores entre bastidores. De hecho, Kubernetes es un tipo de entorno sin servidor porque permite a los desarrolladores y a los equipos de operaciones implementar microservicios sin preocuparse de los detalles de las máquinas donde se despliegan.

Los contenedores proporcionan una solución parcial a los problemas del monolito distribuido mencionados anteriormente en este capítulo. Por ejemplo, Hadoop admite ahora contenedores, lo que permite que cada trabajo tenga sus propias dependencias aisladas.

Advertencia

Las agrupaciones de contenedores no ofrecen la misma seguridad y aislamiento que las máquinas virtuales completas. El escape de contenedores -en términos generales, una clase de exploits de por los que el código de un contenedor obtiene privilegios fuera del contenedor a nivel del SO- es lo suficientemente común como para ser considerado un riesgo para el multiarrendamiento. Mientras que Amazon EC2 es un entorno verdaderamente multiusuario con máquinas virtuales de muchos clientes alojadas en el mismo hardware, un clúster de Kubernetes debería alojar código sólo dentro de un entorno de confianza mutua (por ejemplo, dentro de los muros de una única empresa). Además, los procesos de revisión del código y el escaneo de vulnerabilidades son fundamentales para garantizar que un desarrollador no introduce un agujero de seguridad.

Varios sabores de plataformas de contenedores añaden funciones adicionales sin servidor. Las plataformas de funciones en contenedores ejecutan contenedores como unidades efímeras activadas por eventos, en lugar de servicios persistentes.¹² Esto proporciona a los usuarios la simplicidad de AWS Lambda con toda la flexibilidad de un entorno de contenedores, en lugar del altamente restrictivo tiempo de ejecución de Lambda. Y servicios como AWS Fargate y Google App Engine ejecutan contenedores sin gestionar un clúster informático necesario para Kubernetes. Estos servicios también aíslan completamente los contenedores, evitando los problemas de seguridad asociados a la multitenencia.

La abstracción seguirá abriéndose camino a través de la pila de datos. Considera el impacto de Kubernetes en la gestión de clústeres. Aunque puedes gestionar tu clúster de Kubernetes -y muchos equipos de ingeniería lo hacen-, Kubernetes está ampliamente disponible como servicio gestionado. ¿Qué viene después de Kubernetes? Estamos tan entusiasmados como tú por averiguarlo.

Cómo evaluar servidor frente a sin servidor

¿Por qué querría ejecutar sus propios servidores en lugar de utilizar serverless? Hay varias razones. El coste es un factor importante. Sin servidor tiene menos sentido cuando el uso y el coste superan el coste continuo de ejecutar y mantener un servidor(Figura 4-6). Sin embargo, a cierta escala, los beneficios económicos de la tecnología sin servidor pueden disminuir, y ejecutar servidores se vuelve más atractivo.

Figura 4-6. Coste de un servidor sin servidor frente a la utilización de un servidor

La personalización, la potencia y el control son otras razones importantes para favorecer a los servidores frente a los entornos sin servidor. Algunos frameworks sin servidor pueden ser poco potentes o limitados para determinados casos de uso. He aquí algunas cosas que hay que tener en cuenta al utilizar servidores, sobre todo en la nube, donde los recursos del servidor son efímeros:

Espera que fallen los servidores.

Se producirán fallos en el servidor. Evita utilizar un servidor "copo de nieve especial" que esté demasiado personalizado y sea frágil, ya que esto introduce una vulnerabilidad evidente en tu arquitectura. En su lugar, trata a los servidores como recursos efímeros que puedes crear según tus necesidades y luego eliminar. Si tu aplicación requiere que se instale un código específico en el servidor, utiliza un script de arranque o construye una imagen. Implementa el código en el servidor mediante una canalización CI/CD.

Utiliza clusters y autoescalado.

Aprovecha la capacidad de la nube para aumentar y reducir los recursos informáticos según la demanda. A medida que tu aplicación aumente su uso, agrupa tus servidores de aplicaciones y utiliza las capacidades de autoescalado para escalar horizontalmente tu aplicación de forma automática a medida que crezca la demanda.

Trata tu infraestructura como código.

La automatización no se aplica sólo a los servidores y debe extenderse a tu infraestructura siempre que sea posible. Implementa tu infraestructura (servidores u otros) utilizando gestores de implementación como Terraform, AWS CloudFormation y Google Cloud Implementación Manager.

Utiliza recipientes.

Para cargas de trabajo más sofisticadas o pesadas con dependencias instaladas complejas, considera el uso de contenedores en un único servidor o en Kubernetes.

Nuestros consejos

Aquí encontrarás algunas consideraciones clave que te ayudarán a determinar si la tecnología sin servidor es adecuada para ti:

Tamaño y complejidad de la carga de trabajo

Sin servidor funciona mejor para tareas y cargas de trabajo sencillas y discretas. No es tan adecuado si tienes muchas partes móviles o necesitas mucha potencia de cálculo o memoria. En ese caso, considera el uso de contenedores y un marco de orquestación de flujo de trabajo de contenedores como Kubernetes.

Frecuencia de ejecución y duración

¿Cuántas peticiones por segundo procesará tu aplicación sin servidor? ¿Cuánto tiempo tardará en procesarse cada petición? Las plataformas sin servidor en la nube tienen límites en cuanto a frecuencia de ejecución, concurrencia y duración. Si tu aplicación no puede funcionar limpiamente dentro de estos límites, es hora de considerar un enfoque orientado a contenedores.

Solicitudes y creación de redes

Las plataformas sin servidor suelen utilizar algún tipo de red simplificada y no son compatibles con todas las funciones de red virtual en la nube, como las VPC y los cortafuegos.

Lengua

¿Qué lenguaje utilizas habitualmente? Si no es uno de los lenguajes oficialmente admitidos por la plataforma sin servidor, deberías considerar en su lugar los contenedores.

Limitaciones de tiempo de ejecución

Las plataformas sin servidor no te proporcionan abstracciones completas del sistema operativo. En su lugar, te limitan a una imagen de ejecución específica.

Coste

Las funciones sin servidor son increíblemente cómodas, pero potencialmente caras. Cuando tu función sin servidor procesa sólo unos pocos eventos, tus costes son bajos; los costes aumentan rápidamente a medida que aumenta el número de eventos. Este escenario es una fuente frecuente de facturas sorpresa en la nube.

Al final, la abstracción tiende a ganar. Sugerimos considerar primero el uso de servidores sin servidor y luego servidores -con contenedores y orquestación si es posible- una vez que hayas superado las opciones sin servidor.

Optimización, rendimiento y la guerra de los puntos de referencia

Imagina que eres un multimillonario comprando un nuevo medio de transporte. Has reducido tu elección a dos opciones:

• 787 Business Jet

  • Autonomía: 9.945 millas náuticas (con 25 pasajeros)

  • Velocidad máxima: 0,90 Mach

  • Velocidad de crucero: 0,85 Mach

  • Capacidad de combustible: 101,323 kilogramos

  • Peso máximo al despegue: 227.930 kilogramos

  • Empuje máximo: 128.000 libras

• Tesla Model S a cuadros

  • Autonomía: 560 kilómetros

  • Velocidad máxima: 322 kilómetros/hora

  • 0-100 kilómetros/hora: 2,1 segundos

  • Capacidad de la batería: 100 kilovatios hora

  • Tiempo de vuelta en Nurburgring: 7 minutos, 30,9 segundos

  • Potencia: 1020

  • Par: 1050 lb-ft

¿Cuál de estas opciones ofrece mejores prestaciones? No hace falta saber mucho de coches o aviones para reconocer que se trata de una comparación idiota. Una opción es un avión privado de fuselaje ancho diseñado para operar intercontinentalmente, mientras que la otra es un supercoche eléctrico.

En el ámbito de las bases de datos, vemos continuamente este tipo de comparaciones. Los puntos de referencia o bien comparan bases de datos optimizadas para casos de uso completamente distintos, o bien utilizan escenarios de prueba que no se parecen en nada a las necesidades del mundo real.

Recientemente, hemos visto estallar una nueva ronda de guerras de benchmarks entre los principales proveedores del espacio de datos. Aplaudimos los puntos de referencia y nos alegra ver que muchos proveedores de bases de datos eliminan por fin las cláusulas DeWitt de sus contratos con los clientes.¹³ Aun así, que el comprador tenga cuidado: el espacio de datos está lleno de puntos de referencia sin sentido.¹⁴ He aquí algunos trucos comunes utilizados para colocar un pulgar en la balanza de los puntos de referencia.

Big Data... para los años 90

Los productos que afirman soportar "big data" a escala de petabytes a menudo utilizan conjuntos de datos de referencia lo suficientemente pequeños como para caber fácilmente en el almacenamiento de tu smartphone. Para los sistemas que se basan en capas de almacenamiento en caché para ofrecer rendimiento, los conjuntos de datos de prueba residen totalmente en la unidad de estado sólido (SSD) o en la memoria, y los puntos de referencia pueden mostrar un rendimiento ultraelevado consultando repetidamente los mismos datos. Un conjunto de datos de prueba pequeño también minimiza los costes de RAM y SSD al comparar precios.

Para realizar una evaluación comparativa de los casos de uso en el mundo real, debes simular los datos y el tamaño de la consulta previstos en el mundo real. Evalúa el rendimiento de la consulta y el coste de los recursos basándote en una evaluación detallada de tus necesidades.

Comparaciones de costes absurdas

Las absurdas comparaciones de costes de son un truco habitual cuando se analiza un precio/rendimiento o TCO. Por ejemplo, muchos sistemas MPP no pueden crearse y eliminarse fácilmente aunque residan en un entorno de nube; estos sistemas funcionan durante años una vez configurados. Otras bases de datos admiten un modelo de cálculo dinámico y cobran por consulta o por segundo de uso. Comparar sistemas efímeros y no efímeros en función del coste por segundo no tiene sentido, pero lo vemos todo el tiempo en los análisis comparativos.

Optimización asimétrica

El engaño de la optimización asimétrica aparece de muchas formas, pero he aquí un ejemplo. A menudo, un vendedor comparará un sistema MPP basado en filas con una base de datos columnar utilizando un punto de referencia que ejecuta consultas join complejas sobre datos muy normalizados. El modelo de datos normalizados es óptimo para el sistema basado en filas, pero el sistema columnar sólo alcanzaría todo su potencial con algunos cambios en el esquema. Para empeorar las cosas, los proveedores exprimen sus sistemas con una dosis extra de optimización de las uniones (por ejemplo, preindexando las uniones) sin aplicar un ajuste comparable en la base de datos competidora (por ejemplo, colocando las uniones en una vista materializada).

Caveat Emptor

Como con todo lo relacionado con la tecnología de datos, que el comprador tenga cuidado. Haz tus deberes antes de confiar ciegamente en los puntos de referencia de los proveedores para evaluar y elegir la tecnología.

Las corrientes subterráneas y su impacto en la elección de tecnologías

Como ha visto en este capítulo, un ingeniero de datos tiene mucho que considerar al evaluar las tecnologías. Sea cual sea la tecnología que elijas, asegúrate de comprender cómo apoya las corrientes subyacentes del ciclo de vida de la ingeniería de datos. Volvamos a repasarlos brevemente.

Gestión de datos

Gestión de datos es un área amplia, y en lo que respecta a las tecnologías, no siempre es evidente si una tecnología adopta la gestión de datos como preocupación principal. Por ejemplo, entre bastidores, un proveedor externo puede utilizar las buenas prácticas de gestión de datos -cumplimiento normativo, seguridad, privacidad, calidad de datos y gobernanza-, pero ocultar estos detalles tras una capa limitada de interfaz de usuario. En este caso, al evaluar el producto, ayuda preguntar a la empresa sobre sus prácticas de gestión de datos. He aquí algunos ejemplos de preguntas que deberías hacer:

• ¿Cómo proteges los datos contra las filtraciones, tanto externas como internas?

• ¿Cuál es la conformidad de tu producto con el GDPR, la CCPA y otras normativas sobre privacidad de datos?

• ¿Me permitís alojar mis datos para cumplir esta normativa?

• ¿Cómo garantizáis la calidad de los datos y que estoy viendo los datos correctos en vuestra solución?

Hay muchas otras preguntas que hacer, y éstas son sólo algunas de las formas de pensar sobre la gestión de datos en relación con la elección de las tecnologías adecuadas. Estas mismas preguntas deberían aplicarse también a las soluciones de OSS que estés considerando.

DataOps

Los problemas ocurrirán. Simplemente ocurrirán. Un servidor o una base de datos pueden morir, una región de la nube puede tener una interrupción, puedes implementar código con errores, pueden introducirse datos erróneos en tu almacén de datos y pueden surgir otros problemas imprevistos.

Al evaluar una nueva tecnología, ¿cuánto control tienes sobre la implementación del nuevo código, cómo se te avisará si hay un problema y cómo responderás cuando lo haya? La respuesta depende en gran medida del tipo de tecnología que estés considerando. Si la tecnología es OSS, es probable que seas responsable de configurar el monitoreo, el alojamiento y la implementación del código. ¿Cómo gestionarás los problemas? ¿Cuál es tu respuesta ante incidentes?

Gran parte de las operaciones están fuera de tu control si utilizas una oferta gestionada. Ten en cuenta el acuerdo de nivel de servicio del proveedor, la forma en que te avisa de los problemas y si es transparente sobre la forma en que aborda el caso, incluida la indicación de la fecha prevista de solución.

Arquitectura de datos

Como se explica en en el Capítulo 3, una buena arquitectura de datos implica evaluar las ventajas y desventajas y elegir las mejores herramientas para el trabajo, manteniendo al mismo tiempo la reversibilidad de tus decisiones. Con el panorama de los datos transformándose a gran velocidad, la mejor herramienta para el trabajo es un objetivo móvil. Los objetivos principales son evitar el bloqueo innecesario, garantizar la interoperabilidad en toda la pila de datos y producir un alto retorno de la inversión. Elige tus tecnologías en consecuencia.

Ejemplo de orquestación: Flujo de aire

A lo largo de la mayor parte de este capítulo, hemos evitado activamente hablar demasiado extensamente de una tecnología en particular. Hacemos una excepción con la orquestación, porque este espacio está dominado actualmente por una tecnología de código abierto, Apache Airflow.

Maxime Beauchemin puso en marcha el proyecto Airflow en Airbnb en 2014. Airflow se desarrolló desde el principio como un proyecto de código abierto no comercial. El marco creció rápidamente fuera de Airbnb, convirtiéndose en un proyecto de la Incubadora Apache en 2016 y en un proyecto patrocinado por Apache en 2019.

Airflow disfruta de muchas ventajas, en gran parte debido a su posición dominante en el mercado de código abierto. En primer lugar, el proyecto de código abierto Airflow es extremadamente activo, con un alto índice de commits y un rápido tiempo de respuesta a errores y problemas de seguridad, y el proyecto ha lanzado recientemente Airflow 2, una importante refactorización del código base. En segundo lugar, Airflow goza de un mindshare masivo. Airflow tiene una comunidad vibrante y activa en muchas plataformas de comunicación, como Slack, Stack Overflow y GitHub. Los usuarios pueden encontrar fácilmente respuestas a preguntas y problemas. En tercer lugar, Airflow está disponible comercialmente como servicio gestionado o distribución de software a través de muchos proveedores, como GCP, AWS y Astronomer.io.

Airflow también tiene algunos inconvenientes. Airflow depende de unos pocos componentes básicos no escalables (el programador y la base de datos backend) que pueden convertirse en cuellos de botella en cuanto a rendimiento, escala y fiabilidad; las partes escalables de Airflow siguen un patrón de monolito distribuido. ( Por último, Airflow carece de soporte para muchas construcciones nativas de datos, como la gestión de esquemas, el linaje y la catalogación, y resulta difícil desarrollar y probar los flujos de trabajo de Airflow.

No pretendemos hacer aquí un análisis exhaustivo de las alternativas a Airflow, sino que nos limitaremos a mencionar un par de los principales contendientes en orquestación en el momento de escribir estas líneas. Prefect y Dagster pretenden resolver algunos de los problemas tratados anteriormente replanteando componentes de la arquitectura Airflow. ¿Habrá otros marcos y tecnologías de orquestación de los que no se hable aquí? Prepárate.

Recomendamos encarecidamente que cualquier persona que elija una tecnología de orquestación estudie las opciones aquí comentadas. También deberían familiarizarse con la actividad en el espacio, ya que sin duda se producirán nuevos desarrollos para cuando leas esto.

Ingeniería de software

Como ingeniero de datos, debes esforzarte por la simplificación y la abstracción en toda la pila de datos. Compra o utiliza soluciones de código abierto preconstruidas siempre que sea posible. Eliminar el trabajo pesado indiferenciado debe ser tu gran objetivo. Centra tus recursos -codificación personalizada y herramientas- en áreas que te proporcionen una sólida ventaja competitiva. Por ejemplo, ¿codificar a mano una conexión de base de datos entre tu base de datos de producción y tu almacén de datos en la nube es una ventaja competitiva para ti? Probablemente no. Se trata en gran medida de un problema resuelto. Elige en su lugar una solución lista para usar (de código abierto o SaaS gestionado). El mundo no necesita el millonésimo +1 conector de base de datos a almacén de datos en la nube.

Por otro lado, ¿por qué te compran los clientes? Es probable que tu empresa tenga algo especial en su forma de hacer las cosas. Tal vez sea un algoritmo concreto que impulsa tu plataforma de tecnología financiera. Abstrayendo muchos de los flujos de trabajo y procesos redundantes, puedes seguir recortando, refinando y personalizando las cosas que mueven la aguja para el negocio.

Conclusión

Elegir las tecnologías adecuadas no es tarea fácil, sobre todo cuando cada día surgen nuevas tecnologías y modelos. Hoy es posiblemente el momento más confuso de la historia para evaluar y seleccionar tecnologías. Elegir tecnologías es un equilibrio entre caso de uso, coste, construcción frente a compra y modularización. Enfoca siempre la tecnología del mismo modo que la arquitectura: evalúa las compensaciones y busca decisiones reversibles.

Recursos adicionales

• Cloud FinOps por J. R. Storment y Mike Fuller (O'Reilly)

• "Infraestructura en la nube: La guía definitiva para principiantes" de Matthew Smith

• "El coste de la nube, una paradoja de un billón de dólares" por Sarah Wang y Martín Casado

• Página web "Qué son las FinOps" de la Fundación FinOps

• "Al rojo vivo: el panorama del aprendizaje automático, la IA y los datos (MAD) de 2021" por Matt Turck

• Vídeo de Ternary Data "¿Qué es lo próximo para las bases de datos analíticas? con Jordan Tigani (MotherDuck)".

• "La promesa incumplida de la ausencia de servidor" por Corey Quinn

• "¿Qué es la pila de datos moderna?" por Charles Wang

¹ Para más detalles, consulta "Coste total de oportunidad de la propiedad", de Joseph Reis, en 97 Things Every Data Engineer Should Know (O'Reilly).

² J. R. Storment y Mike Fuller, Cloud FinOps (Sebastopol, CA: O'Reilly, 2019), 6, https://oreil.ly/RvRvX.

³ Este es un punto importante en el que hacen hincapié Storment y Fuller, Cloud FinOps.

⁴ Algunos ejemplos son Google Cloud Anthos y AWS Outposts.

⁵ Raghav Bhargava, "Evolución de la red de perímetro de Dropbox", Dropbox.Tech, 19 de junio de 2017, https://oreil.ly/RAwPf.

⁶ Akhil Gupta, "Escalar a Exabytes y más allá", Dropbox.Tech, 14 de marzo de 2016, https://oreil.ly/5XPKv.

⁷ "Dropbox migra 34 PB de datos a un lago de datos de Amazon S3 para análisis", sitio web de AWS, 2020, https://oreil.ly/wpVoM.

⁸ Todd Hoff, "The Eternal Cost Savings of Netflix's Internal Spot Market", High Scalability, 4 de diciembre de 2017, https://oreil.ly/LLoFt.

⁹ Todd Spangler, "Netflix Bandwidth Consumption Eclipsed by Web Media Streaming Applications", Variety, 10 de septiembre de 2019, https://oreil.ly/tTm3k.

¹⁰ Amir Efrati y Kevin McLaughlin, "Apple's Spending on Google Cloud Storage on Track to Soar 50% This Year", The Information, 29 de junio de 2021, https://oreil.ly/OlFyR.

¹¹ Evan Sangaline, "Running FFmpeg on AWS Lambda for 1.9% the Cost of AWS Elastic Transcoder," Intoli blog, 2 de mayo de 2018, https://oreil.ly/myzOv.

¹² Algunos ejemplos son OpenFaaS, Knative y Google Cloud Run.

¹³ Justin Olsson y Reynold Xin, "Eliminating the Anti-competitive DeWitt Clause for Database Benchmarking", Databricks, 8 de noviembre de 2021, https://oreil.ly/3iFOE.

¹⁴ Para un clásico del género, véase William McKnight y Jake Dolezal, "Data Warehouse in the Cloud Benchmark", GigaOm, 7 de febrero de 2019, https://oreil.ly/QjCmA.