Tl; dr: Con las arquitecturas intensivas en datos, a menudo llega un punto fundamental en el que construir plataformas de datos internas tiene más sentido que comprar soluciones estándar.
El punto de pivote místico
Comprar plataformas de datos estándar es una opción popular para que las nuevas empresas aceleren su negocio, especialmente en las primeras etapas. Sin embargo, ¿es cierto que las empresas que ya han comprado nunca necesitan pivotar para construir, al igual que los proveedores de servicios habían prometido? Hay razones para ambos lados de la vista:
- Necesita pivotar: el costo de compra eventualmente excederá el costo de la construcción, a medida que el costo crece más rápido cuando compra.
- No es necesario pivotar: los requisitos de la plataforma continuarán evolucionando y aumentando el costo de la construcción, por lo que la compra siempre será más barata.
Es un rompecabezas, pero pocos artículos lo han discutido. En esta publicación, profundizaremos en este tema, analizando tres dinámicas que aumentan las razones para la construcción y dos estrategias a considerar al decidir pivotar.
| Dinámica | Estrategias pivote |
| – Crecimiento del crédito técnico – Cambio de personaje del cliente – Prioridad desalineada |
-Pivotación basada en costos -Pivotación basada en el valor |
Crecimiento de crédito técnico
Todo comenzó fuera del alcance de la plataforma de datos. Lo desea o no, para mejorar la eficiencia o su operación, su empresa necesita acumularse Créditos técnicos en tres niveles diferentes. Al darse cuenta o no, comenzarán a facilitarle la construcción.
¿Qué es el crédito técnico? Mira esto articil publicado en ACM.
Esos tres niveles de Créditos técnicos son:
| Crédito técnicos | Propósitos clave |
| Orquestación de clúster | Mejora la eficiencia en la gestión de grupos de Kubernetes de sabor múltiple. |
| Orquestación de contenedores | Mejorar la eficiencia en la gestión de microservicios y pilas de código abierto |
| Orquestación de funciones | Mejore la eficiencia mediante la configuración de un FAA interno (función como un servicio) que abstrae todos los detalles de la infraestructura. |
Para la orquestación de clúster, típicamente hay tres sabores diferentes de clústeres de Kubernetes.
- Grupos para microservicios
- Grupos para servicios de transmisión
- Grupos para el procesamiento por lotes
Cada uno de ellos requiere diferentes estrategias de provisión, especialmente en diseño de red y autoescalado. Mira esto correo Para una descripción general de las diferencias de diseño de red.
Para la eficiencia de la orquestación de contenedores, una posible forma de acelerar es extender el clúster Kubernetes con una definición de recursos personalizado (CRD). En esta publicación, compartí cómo funciona KubeBuilder y algunos ejemplos construidos con ella. Por ejemplo, una plataforma DS interna de CRD.
Para la eficiencia de orquestación de funciones, requirió una combinación del SDK y la infraestructura. Muchas organizaciones utilizarán herramientas de andamios para generar esqueletos de código para microservicios. Con esta inversión de control, la tarea para el usuario simplemente está llenando el cuerpo del manejador de REST-API.
En esto correo En la ciencia de datos, la mayoría de los servicios en el viaje MLOPS se construyen utilizando FAA. Especialmente para los servicios de servicio de modelos, los ingenieros de aprendizaje automático solo necesitan completar algunas funciones esenciales, que son fundamentales para presentar la carga, la transformación y el enrutamiento de solicitudes.
La siguiente tabla comparte el Viaje clave del usuario y Área de control de diferentes niveles de Créditos técnicos.
| Crédito técnicos | Viaje clave del usuario | Área de control |
| Grupo Orquestación |
Autor a sí mismo en la creación de grupos K8s de múltiples sabor. | – Política para asignación de región, zona e IP CIDR – Pesación de redes – Política, por ejemplo, el aprovisionamiento – Security & OS Harden – Módulos de Terraform y tuberías CI/CD |
| Orquestación de contenedores | Autor a la implementación de servicios, implementación de la pila de código abierto y edificio CRD | – GITOPS para lanzamientos de recursos de clúster – Política para la creación de ingresos – Política para la definición de recursos del cliente – Política para la escala automática de clúster – Política para la recolección y monitoreo de métricos – Seguimiento de costos |
| Función Orquestación |
Concéntrese únicamente en la implementación de la lógica de negocios llenando esqueletos de funciones predefinidas. | – Control de identidad y permiso – Gestión de configuración – Punto de control de estado interno – Programación y migración – Descubrimiento de servicios – Monitoreo de la salud |
Con el crecimiento de TCréditos ecínicosel costo de la construcción se reducirá.
Sin embargo, la transferibilidad difFers para diferentes niveles de créditos técnicos. De abajo hacia arriba, se vuelve cada vez menos transferible. Podrá hacer cumplir la gestión constante de la infraestructura y reutilizar microservicios. Sin embargo, es difícil reutilizar el crédito técnico por construir FAA en diferentes temas. Además, la disminución de los costos de construcción no significa que necesite reconstruir todo usted mismo. Para un análisis completo de compensación de compra de compilación, dos factores más juegan un papel, que son:
- Cambio de personalidad del cliente
- Prioridad desalineada
Cambio de personalidad del cliente
A medida que su empresa crece, pronto se dará cuenta de que la distribución de personal para plataformas de datos está cambiando.
Cuando es pequeño, la mayoría de sus usuarios son científicos de datos y analistas de datos. Exploran datos, validan ideas y generan métricas. Sin embargo, cuando se lanzan más características del producto centradas en los datos, los ingenieros comienzan a escribir trabajos de chispa para hacer una copia de seguridad de sus servicios en línea y modelos de ML. Esas tuberías de datos son ciudadanos de primera clase Al igual que los microservicios. Tal cambio de persona, que hace que un viaje de desarrollo de la tubería de datos GITOPS sea aceptable e incluso bienvenido.
Prioridad desalineada
Habrá desalineaciones entre los proveedores de SaaS y usted, simplemente porque todos necesitan actuar en el mejor interés de su propia empresa. La desalineación inicialmente parece menor, pero podría empeorar gradualmente con el tiempo. Esas posibles desalineaciones son:
| Prioridad | Proveedor de SaaS | Tú |
| Priorización de características | Beneficio de la mayoría de los clientes | Beneficios de su organización |
| Costo | Impacto secundario (rotación de clientes potenciales) | Impacto directo (necesita pagar más) |
| Integración del sistema | Estándar Interfaz |
Integración personalizable |
| Agrupación de recursos | Compartir entre sus inquilinos | Compartir en su sistema interno |
Para la agrupación de recursos, los sistemas de datos son ideales para ubicar conjuntamente con sistemas en línea, ya que sus cargas de trabajo generalmente alcanzan su punto máximo en diferentes momentos. La mayoría de las veces, los sistemas en línea experimentan un uso máximo durante el día, mientras que las plataformas de datos alcanzan su punto máximo por la noche. Con más compromisos con su proveedor de la nube, los beneficios de la agrupación de recursos se vuelven más significativos. Especialmente cuando compra cuotas de instancia reservadas anuales, combinar la carga de trabajo en línea y fuera de línea le brinda un poder de negociación más fuerte. Sin embargo, los proveedores de SaaS priorizarán la pivotación a la arquitectura sin servidor para permitir la agrupación de recursos entre sus clientes, mejorando así su margen de beneficio.
¡Pivote! ¡Pivote! ¿Pivote?
Incluso con el costo de la disminución de la construcción y el aumento de las desalineaciones, la construcción nunca será una opción fácil. Requiere experiencia en el dominio y una inversión a largo plazo. Sin embargo, la buena noticia es que no tiene que realizar un interruptor completo. Hay razones convincentes para adoptar un enfoque híbrido o un giro paso a paso, maximizando el retorno de la inversión de la compra y la construcción. Puede haber dos maneras en el futuro:
- Pivote basado en costos
- Pivote basado en el valor
Descargo de responsabilidad: por la presente presento mi perspectiva. Presenta algunos principios generales, y se le recomienda que haga su propia investigación para la validación.
Enfoque uno: pivote basado en costos
La regla 80/20 también se aplica bien a los trabajos de Spark. El 80% de los trabajos de Spark se ejecutan en producción, mientras que el 20% restante es enviado por usuarios del entorno Dev/Sandbox. Entre el 80% de los trabajos en producción, el 80% son pequeños y directos, mientras que el 20% restante es grande y complejo. Una máquina de chispa premium se distingue principalmente en trabajos grandes y complejos.
¿Quiere entender por qué Databricks Photon funciona bien en trabajos de chispa complejos? Mira esto correo por Huong.
Además, los entornos Sandbox o de desarrollo requieren controles de gobierno de datos más fuertes y capacidades de descubribilidad de datos, que requieren sistemas bastante complejos. En contraste, el entorno de producción se centra más en el control de GITOPS, que es más fácil de construir con las ofertas existentes de la nube y la comunidad de código abierto.
Si puede construir un sistema de enrutamiento dinámico basado en costos, como un bandido múltiple, para enrutar trabajos de chispas menos complejos a una plataforma interna más asequible, puede ahorrar una cantidad significativa de costo. Sin embargo, con dos requisitos previos:
- Artefacto de la plataforma: Una plataforma como Databricks puede tener su propia notación SDK o cuaderno que es específica para el ecosistema de Databricks. Para lograr un enrutamiento dinámico, debe hacer cumplir los estándares para crear artefactos agnósticos de plataforma que puedan ejecutarse en diferentes plataformas. Esta práctica es crucial para evitar el bloqueo del proveedor a largo plazo.
- Parches de componentes faltantes (p.ej, Metastore de colmena): es un antipatrón tener dos sistemas duplicados uno al lado del otro. Pero puede ser necesario cuando pivotas para construir. Por ejemplo, Spark de código abierto no puede aprovechar el catálogo de Unidad de Databricks a su capacidad completa. Por lo tanto, es posible que deba desarrollar un servicio de catálogo, como una colmena Metastore, para su plataforma interna.
Tenga en cuenta también que una pequeña proporción de trabajos complejos puede explicar una gran parte de su factura. Por lo tanto, se requiere realizar una investigación exhaustiva para su caso.
Enfoque dos: pivote basado en el valor
El segundo enfoque de pivote se basa en cómo la tubería de dosis genera valores para su empresa.
- Operativo: datos como producto como valor
- Analítico: información como valores
El marco de desglose se inspira en este artículo, MLOPS: tuberías continuas de entrega y automatización en el aprendizaje automático. Trae un concepto importante llamado simetría experimental-operacional.
Clasificamos nuestras tuberías de datos en dos dimensiones:
- Basado en la complejidad del artefacto, se clasifican en tuberías de bajo código, secuencias de comandos y de alto código.
- Según el valor que genera, se clasifican en tuberías operativas y analíticas.
Las tuberías de alto código y operativas requieren ESTADAGIA-> Simetría de producción Para una rigurosa revisión y validación del código. Las scripting y las tuberías analíticas requieren dev-> simetría de puesta en escena Para la velocidad de desarrollo rápido. Cuando una tubería analítica tiene una visión analítica importante y debe ser democratizado, debería ser traSe aplicó a una tubería operativa con revisiones de código, ya que la salud de esta tubería será crítica para muchos otros.
La simetría total, Dev -> STG -> PRDno se recomienda para secuencias de comandos y artefactos de alto código.
Examinemos los principios operativos y los requisitos clave de estas diferentes tuberías.
| Tipo de tubería | Principio operativo | Requisitos clave de la plataforma |
| Datos como producto (operativo) | GITOPS estricto, Rollback en el fracaso | Estabilidad e integración interna cercana |
| Información como valores (analítico) | Iteración rápida, vuelco al fracaso | Experiencia del usuario y velocidad del desarrollador |
Debido a las diferentes formas de producir valor de valor y operación, puede:
- Tuberías operativas de pivote: dado que la integración interna es más crítica para la tubería operativa, tiene más sentido pivotar las plataformas internas primero.
- Tuberías de código bajo pivote: la tubería de código bajo también se puede cambiar fácilmente debido a su naturaleza de código bajo.
Por fin
Pivote o no un pivote, no es una llamada fácil. En resumen, estas son prácticas que debe adoptar independientemente de la decisión que tome:
- Preste atención al crecimiento de su crédito técnico interno y actualice su evaluación del costo total de propiedad.
- Promover Artefactos agnósticos de la plataforma Para evitar el bloqueo del proveedor.
Por supuesto, cuando realmente necesitas pivotar, tener una estrategia exhaustiva. ¿Cómo cambia la IA nuestra evaluación aquí?
- AI hace posible a la rápida-> código alto. Acelera drásticamente el desarrollo de tuberías operativas y analíticas. Para mantenerse al día con la tendencia, es posible que desee considerar comprar o construir si tiene confianza.
- La IA exige una mayor calidad de los datos. Garantizar la calidad de los datos será más crítica tanto para las plataformas internas como para los proveedores SaaS.
Aquí están mis pensamientos sobre este tema impopular, Pivotando de compra a construcción. Déjame saber tus pensamientos al respecto. ¡Salud!