Categories
54cuatro

Data Mesh. ¿Qué es?

Se viene hablando mucho sobre data mesh, y existen muy buenas explicaciones respecto al tema.

Muy buen video Zhamak Dehgani

#DataMesh o Malla de Datos, es un término que hace mención a la evolución de los pipelines de datos, abordado desde 4 dimensiones:

  • Propiedad y arquitectura descentralizada de datos orientada al dominio
  • Datos como producto.
  • Infraestructura de datos de autoservicio como plataforma
  • Gobierno federado.

Cada principio impulsa una nueva visión lógica de la arquitectura técnica y la estructura organizativa.

Para entender que es un #dominio, sugerimos leer acerca de DDD (domain driven design).

Objetivo de la Malla de Datos

En la actualidad existen 2 grandes modelos de gestión de datos, el #EDW (Datawarehouse) y el #Datalake, y aunque se impulsa un concepto híbrido denominado #lakehouse, la realidad es que sigue existiendo complejidades asociadas a las fallas constantes de los #ETL, un incremento exponencial de los #data #pipelines y eso genera cada día mayor necesidad de administración.

La malla de datos reconoce y respeta las diferencias entre estos dos planos: la naturaleza y la topología de los datos, los diferentes casos de uso, las personas individuales de los consumidores de datos y, en última instancia, sus diversos patrones de acceso. Sin embargo, intenta conectar estos dos planos bajo una estructura diferente: un modelo invertido y una topología basada en dominios y no en una pila de tecnología.- con un enfoque en el plano de datos analíticos.

El objetivo de la malla de datos es crear una base para obtener valor de los datos analíticos y los hechos históricos a escala . La escala se aplica al cambio constante del panorama de datos , la proliferación de fuentes de datos y consumidores , la diversidad de transformación y procesamiento que requieren los casos de uso , la velocidad . de respuesta al cambio .

Modelo de Data Mesh

Malla de datos

Descripción de los pilares

  • Propiedad y arquitectura descentralizada de datos orientada al dominio: este punto hace referencia a la transferencia de la propiedad de los datos a los responsables de dominio. Un experte de dominio según DDD es aquel con conocimientos específicos sobre un sector/área de la compañia, como gerencias, departamentos, etc. Esta transferencia hace que los expertos de dominios, sean los dueños y por ende se delega en ellos la responsabilidad de asegurar la calidad y seguridad de la data.
  • Datos como producto: en este punto, el objetivo es que los dominios sean capaces de generar sus productos de datos. Bajo un concepto de Product Owner, la idea es que cada responsable pueda mantener, validar y mejorar la calidad de la información; buscando que además la información sea colaborativa y pueda ser consumida por diferentes actores interesados.
  • Infraestructura de datos de autoservicio como plataforma: este ítem busca la simplificación de la gestión de la plataforma, permitiendo a los usuarios especialistas de dominios poder trabajar sobre la data sin depender de especialistas.
  • Gobierno federado: la importancia de la gobernanza no puede quedar de lado. Este punto refiere a la necesidad de cumplir con los puntos de seguridad/compliance/políticas corporativas, con el objetivo de asegurar la privacidad, el cumplimiento normativo y la seguridad.

[popup_anything id=”2076″]

Categories
54cuatro

Administrando contenedores con GitOps

Como analizamos en notas anteriores acerca de #GitOps, es importante destacar que su adopción permite gestionar las configuraciones usando Git, y cobra vital importancia cuando hablamos de contenedores dado que se construyende forma declarativa, la configuración de las aplicaciones y sus entornos de implementación son realizadas de manera declarativas (yaml/json).

¿Porque es importante GitOps cuando hablamos de contenedores?

Recordemos que cuando desplegamos un #container basicamente pulleamos código. De esta manera, poder tener un control de versiones permite controlar los despliegues de los #contenedores, por ejemplo para recuperarse de cualquier implementación fallida.

Ademas por medio de herramientas es mucho mas transparente realizar cambios operativos, por ejemplo, solucionar un problema de producción mediante un ‘pull request’ en lugar de realizar cambios en todo el sistema productivo.

Las herramientas GitOps como ArgoCD o FluxCD permiten actuar como una fuente unica de verdad, garantizando los estados de los clusteres a partir del control de las configuraciones.

Deployment Pipeline

Usando CI/CD con GitOps

Estas herramientas estan monitoreando los repos con las configuraciones para detectar cambios o imágenes nuevas, de manera de desencadenar automáticamente implementaciones o cambios de configuraciones.

Estas herramientas actuan como CI/CD sin requerir de herramientas adicionales, y el despliegue se encuentra asegurado debido a que funcionan en un formato denominado “atomico y transaccional”, de manera que existen logs que garantizan que las transacciones se realicen correctamente o en caso de fallar no sean aplicados los cambios.

GitOps en la nube

El desarrollo de implementacionees en #kubernetes requiere el despliegue de aplicaciones, clusteres, entornos, etc; y los despliegues en la nube no son una excepción.

Por ese motivo, comprender como GitOps se integra con aplicaciones #cloud es importante para poder crear #pipelines CI/CD.

En el caso de #Azure, se propone la creación de una integración con la solucion #AzureDevOps.

Arquitectura de CI/CD con GitOps
  • El repositorio de aplicaciones contiene el código de la aplicación. Las plantillas de implementación de la aplicación residen en este repositorio en un formato genérico, como Helm o Kustomize. Cualquier cambio en este repo dispara el proceso de implementación.
  • El registro de contenedor contiene todas las imágenes propias y de terceros que se usan en los entornos de Kubernetes.
  • En este caso la integración esta realizada con #FluxCD, como servicio que se ejecuta en cada clúster y es responsable de mantener el estado deseado. Como mencionamos mas arriba, este servicio sondea el repositorio de GitOps en busca de cambios en su clúster y los aplica.
  • Dentro de este esquema propuesto por Microsoft incorporan #AzureArc, una herramienta que ofrece una administración simplificada para Windows, Linux, SQL Server y para este caso particular, los clústeres de Kubernetes. En este caso,  Azure Arc sirve para los diferentes entornos necesarios para la aplicación. Por ejemplo, un único clúster puede atender a un entorno de desarrollo y QA a través de espacios de nombres diferentes. 

Beneficios y Conclusión

Git es el estándar de facto de los sistemas de control de versiones y es una herramienta de desarrollo de software común para la mayoría de los desarrolladores y equipos de software. Esto facilita que los desarrolladores familiarizados con Git se conviertan en colaboradores multifuncionales y participen en GitOps. Ademas un sistema de control de versiones le permite a un equipo rastrear todas las modificaciones a la configuración de un sistema.

GitOps aporta transparencia y claridad a las necesidades de infraestructura de una organización en torno a un repositorio central ue resuelven de forma muy simple las implementaciones y los rollbacks en infraestructuras complicadas.


[popup_anything id=”2076″]