Trabajar con datos confidenciales o en un entorno altamente regulado requiere una infraestructura en la nube segura para el procesamiento de datos. La nube puede parecer un entorno abierto en Internet y plantear problemas de seguridad. Cuando comienza su recorrido con Azure y no tiene suficiente experiencia con la configuración de recursos, es fácil cometer errores de diseño e implementación que pueden afectar la seguridad y la flexibilidad de su nueva plataforma de datos. En esta publicación, describiré los aspectos más importantes del diseño de un marco de adaptación a la nube para una plataforma de datos en Azure.
Una zona de aterrizaje de Azure es la base para implementar recursos en la nube pública. Contiene elementos esenciales para una plataforma sólida. Estos elementos incluyen redes, administración de identidades y acceso, seguridad, gobernanza y cumplimiento. Al implementar una zona de aterrizaje, las organizaciones pueden optimizar el proceso de configuración de su infraestructura, lo que garantiza la utilización de las mejores prácticas y pautas.
Una zona de aterrizaje de Azure es un entorno que sigue principios de diseño clave para permitir la migración, modernización y desarrollo de aplicaciones. En Azure, las suscripciones se utilizan para aislar y desarrollar recursos de aplicaciones y plataformas. Se clasifican de la siguiente manera:
- Zonas de aterrizaje de aplicaciones:Suscripciones dedicadas a alojar recursos específicos de la aplicación.
- Zona de aterrizaje de la plataforma: Suscripciones que contienen servicios compartidos, como identidad, conectividad y recursos de gestión proporcionados para zonas de aterrizaje de aplicaciones.
Estos principios de diseño ayudan a las organizaciones a operar con éxito en un entorno de nube y escalar una plataforma.
La implementación de una plataforma de datos en Azure implica un diseño de arquitectura de alto nivel en el que se seleccionan recursos para la ingesta, transformación, distribución y exploración de datos. El primer paso puede requerir un diseño de zona de aterrizaje. Si necesita una plataforma segura que siga las mejores prácticas, es fundamental comenzar con una zona de aterrizaje. Le ayudará a organizar los recursos dentro de las suscripciones y los grupos de recursos, definir la topología de la red y garantizar la conectividad con los entornos locales a través de VPN, al mismo tiempo que se adhiere a las convenciones y estándares de nomenclatura.
Diseño de arquitectura
Para adaptar una arquitectura a una plataforma de datos es necesario seleccionar cuidadosamente los recursos. Azure ofrece recursos nativos para plataformas de datos como Azure Synapse Analytics, Azure Databricks, Azure Data Factory y Microsoft Fabric. Los servicios disponibles ofrecen diversas formas de lograr objetivos similares, lo que permite flexibilidad en la selección de la arquitectura.
Por ejemplo:
- Ingestión de datos: Azure Data Factory o Synapse Pipelines.
- Proceso de datos: Azure Databricks o Apache Spark en Synapse.
- Análisis de datos: Paneles de Power BI o Databricks.
Podemos utilizar Apache Spark y Python o herramientas de arrastrar y soltar de código reducido. Varias combinaciones de estas herramientas pueden ayudarnos a crear la arquitectura más adecuada según nuestras habilidades, casos de uso y capacidades.
Azure también permite utilizar otros componentes como Snowflake o crear composiciones propias mediante software de código abierto, máquinas virtuales (VM) o Kubernetes Service (AKS). Podemos aprovechar las máquinas virtuales o AKS para configurar servicios de procesamiento de datos, exploración, orquestación, IA o ML.
Estructura típica de una plataforma de datos
Una plataforma de datos típica en Azure debe incluir varios componentes clave:
1. Herramientas para la ingesta de datos desde orígenes a una cuenta de almacenamiento de Azure. Azure ofrece servicios como Azure Data Factory, Azure Synapse Pipelines o Microsoft Fabric. Podemos usar estas herramientas para recopilar datos desde orígenes.
2. Data Warehouse, Data Lake o Data Lakehouse: Dependiendo de sus preferencias de arquitectura, podemos seleccionar diferentes servicios para almacenar datos y un modelo de negocio.
- Para Data Lake o Data Lakehouse, podemos utilizar Databricks o Fabric.
- Para el almacén de datos podemos seleccionar Azure Synapse, Snowflake o MS Fabric Warehouse.
3. Para orquestar el procesamiento de datos en Azure contamos con Azure Data Factory, Azure Synapse Pipelines, Airflow o Databricks Workflows.
4. La transformación de datos en Azure puede ser gestionada por varios servicios.
- Para Apache Spark: Databricks, Azure Synapse Spark Pool y MS Fabric Notebooks,
- Para la transformación basada en SQL, podemos usar Spark SQL en Databricks, Azure Synapse o MS Fabric, T-SQL en SQL Server, MS Fabric o Synapse Dedicated Pool. Como alternativa, Snowflake ofrece todas las capacidades de SQL.
Suscripciones
Un aspecto importante del diseño de la plataforma es la planificación de la segmentación de las suscripciones y los grupos de recursos en función de las unidades de negocio y el ciclo de vida del desarrollo de software. Es posible utilizar suscripciones independientes para entornos de producción y de no producción. Con esta distinción, podemos lograr un modelo de seguridad más flexible, políticas independientes para entornos de producción y de prueba y evitar limitaciones de cuotas.
Redes
Una red virtual es similar a una red tradicional que opera en su centro de datos. Azure Virtual Networks (VNet) proporciona una capa de seguridad básica para su plataforma. Al deshabilitar los puntos de conexión públicos para los recursos, se reducirá significativamente el riesgo de fugas de datos en caso de pérdida de claves o contraseñas. Sin puntos de conexión públicos, los datos almacenados en las cuentas de almacenamiento de Azure solo son accesibles cuando se conecta a su VNet.
La conectividad con una red local permite una conexión directa entre los recursos de Azure y las fuentes de datos locales. Según el tipo de conexión, el tráfico de comunicación puede pasar por un túnel cifrado a través de Internet o por una conexión privada.
Para mejorar la seguridad en una red virtual, puede usar grupos de seguridad de red (NSG) y firewalls para administrar las reglas de tráfico entrante y saliente. Estas reglas le permiten filtrar el tráfico en función de direcciones IP, puertos y protocolos. Además, Azure permite enrutar el tráfico entre subredes, redes virtuales y locales e Internet. El uso de tablas de rutas personalizadas permite controlar dónde se enruta el tráfico.
Convención de nomenclatura
Una convención de nomenclatura establece una estandarización para los nombres de los recursos de la plataforma, lo que los hace más autodescriptivos y más fáciles de administrar. Esta estandarización ayuda a navegar por diferentes recursos y filtrarlos en Azure Portal. Una convención de nomenclatura bien definida le permite identificar rápidamente el tipo, el propósito, el entorno y la región de Azure de un recurso. Esta coherencia puede ser beneficiosa en sus procesos de CI/CD, ya que los nombres predecibles son más fáciles de parametrizar.
Al considerar la convención de nombres, debe tener en cuenta la información que desea capturar. El estándar debe ser fácil de seguir, coherente y práctico. Vale la pena incluir elementos como la organización, la unidad de negocios o el proyecto, el tipo de recurso, el entorno, la región y el número de instancia. También debe considerar el alcance de los recursos para garantizar que los nombres sean únicos dentro de su contexto. Para ciertos recursos, como las cuentas de almacenamiento, los nombres deben ser únicos a nivel global.
Por ejemplo, un espacio de trabajo de Databricks podría nombrarse utilizando el siguiente formato:
Ejemplos de abreviaturas:
Una convención de nomenclatura completa normalmente incluye el siguiente formato:
- Tipo de recurso: Una abreviatura que representa el tipo de recurso.
- Nombre del proyecto: Un identificador único para su proyecto.
- Ambiente: El entorno que admite el recurso (por ejemplo, desarrollo, control de calidad, producción).
- Región: La región geográfica o el proveedor de la nube donde se implementa el recurso.
- Instancia: Un número para diferenciar entre múltiples instancias del mismo recurso.
Implementar la infraestructura a través del portal de Azure puede parecer sencillo, pero a menudo implica numerosos pasos detallados para cada recurso. La infraestructura altamente segura requerirá configuración de recursos, redes, puntos de conexión privados, zonas DNS, etc. Los recursos como Azure Synapse o Databricks requieren una configuración interna adicional, como configurar Unity Catalog, administrar ámbitos secretos y configurar ajustes de seguridad (usuarios, grupos, etc.).
Una vez que termine con el entorno de prueba, deberá replicar la misma configuración en los entornos de control de calidad y producción. Aquí es donde es fácil cometer errores. Para minimizar los posibles errores que podrían afectar la calidad del desarrollo, se recomienda utilizar un enfoque de Infraestructura como código (IasC) para el desarrollo de la infraestructura. IasC le permite crear infraestructura en la nube como código en Terraform o Biceps, lo que le permite implementar múltiples entornos con configuraciones consistentes.
En mis proyectos en la nube, utilizo aceleradores para iniciar rápidamente nuevas configuraciones de infraestructura. Microsoft también ofrece aceleradores que se pueden utilizar. Almacenar una infraestructura como código en un repositorio ofrece beneficios adicionales, como control de versiones, seguimiento de cambios, realización de revisiones de código e integración con canales de DevOps para administrar y promover cambios en todos los entornos.
Si su plataforma de datos no maneja información confidencial y no necesita una plataforma de datos altamente segura, puede crear una configuración más simple con acceso a Internet público sin redes virtuales (VNet), VPN, etc. Sin embargo, en un área altamente regulada, se requiere un plan de implementación completamente diferente. Este plan implicará la colaboración con varios equipos dentro de su organización, como los equipos de DevOps, Plataforma y Redes, o incluso recursos externos.
Será necesario establecer una infraestructura de red segura, recursos y seguridad. Solo cuando la infraestructura esté lista, se podrán iniciar las actividades relacionadas con el desarrollo del procesamiento de datos.
Si este artículo te ha parecido interesante, te invito a que me lo expreses haciendo clic en el botón de “aplausos” o dándole “Me gusta” en LinkedIn. Tu apoyo es muy valioso. Si tienes alguna pregunta o quieres recibir un consejo, no dudes en ponerte en contacto conmigo en LinkedIn.