Etiqueta: GCP

Categories
54cuatro

Comparando plataformas de datos en la nube: Databricks vs Snowflake

La adopción de soluciones de datos en la nube ha estado en aumento en los últimos años y dos de las principales opciones son Databricks y Snowflake. Ambas ofrecen servicios en la nube, de hecho pueden ser instaladas tanto en AWS como en Azure. Pero cada una tiene sus propias fortalezas y debilidades. En este artículo, se comparan ambas plataformas en términos de su arquitectura, capacidad de procesamiento y herramientas de análisis.

Snowflake vs Databricks — Datagrom | Data Science Consulting

Ambas plataformas son muy eficientes en el procesamiento y análisis de datos a gran escala, pero tienen diferencias significativas en cuanto a su funcionalidad y enfoque. #Databricks se enfoca en el procesamiento de datos y el análisis de datos en tiempo real, mientras que #Snowflake se centra en la gestión de datos y el almacenamiento de datos en la nube. Ambas plataformas son muy utilizadas en la industria y son una buena opción para cualquier empresa que busque procesar y analizar grandes cantidades de datos.

In Snowflake vs. Databricks Feud, the Only Conclusion Is: DataOps Needs All the Help It Can Get

Veamos algunos puntos particulares. Empecemos con:

Arquitectura

Databricks se basa en Apache Spark y tiene una arquitectura abierta y flexible que permite a los usuarios integrar diversas fuentes de datos y herramientas de análisis. También tiene integración nativa con Microsoft Azure y Amazon Web Services (AWS).

Snowflake utiliza un enfoque basado en la nube y se centra en el almacenamiento de datos. Tiene una arquitectura de tres capas y utiliza una base de datos columnar.

Capacidad de procesamiento

Databricks tiene la capacidad de procesar grandes volúmenes de datos y realizar tareas de procesamiento en paralelo en múltiples nodos. Además, su capacidad de procesamiento se puede escalar según sea necesario para manejar grandes cargas de trabajo.

Snowflake también puede procesar grandes cantidades de datos, pero se enfoca en la velocidad y la eficiencia. Además, su arquitectura basada en la nube permite a los usuarios escalar fácilmente el procesamiento según sea necesario.

Herramientas de análisis

Databricks tiene una variedad de herramientas de análisis, incluyendo librerías de ciencia de datos y herramientas de visualización. También tiene integración con herramientas de terceros, como Tableau y Power BI.

Snowflake se centra en el almacenamiento de datos y la consulta de datos. Tiene una interfaz de usuario sencilla que permite a los usuarios consultar los datos y crear informes.

Finalizando, nos llama mucho la atención que Snowflake y Databricks, dos empresas que inicialmente tenían objetivos muy diferentes, han estado compitiendo en un mercado cada vez más convergente. Snowflake se enfocó en equipos de BI mientras que Databricks se enfocó en equipos de ciencia de datos, pero ahora ambos están expandiéndose a los dominios del otro, creando una verdadera batalla por la “Plataforma de Datos en la Nube”. La propiedad de los datos es esencial en esta competencia, y ambas empresas comenzaron con sistemas de almacenamiento cerrados. Pero, para sorpresa de muchos, Databricks sorprendió a Snowflake al abrir partes de Delta Lake, lo que provocó que Snowflake siguiera el ejemplo adoptando Apache Iceberg. En respuesta, Databricks tomó medidas drásticas y donó todo Delta Lake a la Fundación Linux con el lanzamiento de Delta Lake 2.0, dejando en claro su compromiso con un estándar abierto para el almacenamiento de datos.

Ambas plataformas ofrecen soluciones de datos en la nube y tienen sus propias fortalezas y debilidades. Databricks es ideal para usuarios que requieren una plataforma de análisis de datos altamente personalizable, mientras que Snowflake es ideal para usuarios que necesitan una plataforma de almacenamiento de datos rápida y eficiente.

Alternativas a estas plataformas

Existen varias alternativas a Snowflake y Databricks en el mercado, dependiendo de las necesidades y requisitos de la empresa. Algunas de estas alternativas incluyen:

  • Almacenes de datos en la nube: otras opciones populares incluyen Amazon #Redshift, Google #BigQuery, Microsoft Azure #Synapse Analytics y #Oracle Autonomous Data Warehouse.
  • Plataformas de análisis unificado: hay varias opciones, como Google Cloud Dataproc, Apache Flink, Apache Beam y Apache Storm.
  • Plataformas de ciencia de datos: algunas opciones incluyen Google Cloud AI Platform, Microsoft Azure Machine Learning, IBM Watson Studio y Amazon SageMaker.

Cada una de estas opciones tiene sus propias ventajas y desventajas, y la elección dependerá de los requisitos específicos de la empresa. Es importante hacer una investigación exhaustiva y evaluar las diferentes opciones antes de tomar una decisión.

Si estás buscando alternativas a Snowflake y Databricks para la gestión de tus datos en la nube, te recomendamos considerar Redshift de #AWS y Synapse de #Azure. Ambas plataformas ofrecen soluciones de almacenamiento y procesamiento de datos escalables y seguras.

AWS se destaca por su proceso constante de innovación y la incorporación de nuevas funciones y aplicaciones a su ecosistema de datos. Con Redshift, los usuarios pueden almacenar y analizar grandes cantidades de datos utilizando herramientas de análisis de datos de código abierto, como #SQL y #Python. Además, Redshift es altamente escalable y puede manejar desde pequeñas cargas de trabajo hasta grandes conjuntos de datos.

Por otro lado, Synapse de Azure se distingue por su simplicidad y robustez. La plataforma ofrece una amplia gama de herramientas integradas para el procesamiento de datos, desde la ingestión hasta el análisis. Además, la adopción de tecnología de Azure es fácil y rápida, lo que permite a los usuarios obtener resultados inmediatos.

#BigQuery es una solución de almacenamiento y análisis de datos en la nube altamente escalable y eficiente que se ha vuelto muy popular entre los usuarios de #GCP. Ofrece una variedad de características avanzadas, como la capacidad de analizar datos en tiempo real y la integración con otras herramientas de Google, como #DataStudio y #TensorFlow.

Sin embargo, a nosotros no nos resulta efectiva la calidad de su soporte técnico. En comparación con AWS y Microsoft, el soporte proporcionado por Google aún tiene mucho por mejorar.

En resumen, tanto Redshift de AWS como Synapse de Azure son excelentes alternativas a considerar si estás buscando una plataforma de gestión de datos en la nube segura, escalable y eficiente.

Categories
54cuatro

Comparativa entre herramientas de ETL

ETL es un acrónimo que significa Extracción, Transformación y Carga. Es un proceso utilizado en la gestión de datos para recopilar datos de diferentes fuentes, limpiarlo y transformarlo en un formato adecuado para su análisis y utilización en un sistema de información. Luego se carga en una base de datos o sistema de almacenamiento para su uso futuro. Es una técnica comúnmente utilizada en la integración de datos.

Existen herramientas open source, comerciales e incluso serverless provistas por cloud providers.
ETL (Extraction, Transformation & Load) – La Taberna del BI

¿Que herramienta de #ETL usar?

Talend es una plataforma de integración de datos que permite la conexión, la transformación y la integración de datos entre diferentes sistemas. Utiliza una interfaz gráfica de usuario para diseñar flujos de trabajo de integración de datos, lo que facilita la creación de tareas de integración de datos para usuarios sin experiencia en programación. Además, #Talend ofrece una amplia gama de componentes preconstruidos que se pueden utilizar para conectarse a diferentes fuentes de datos, como bases Talend Data Fabric - Opiniones, precios y características - Capterra Colombia 2023de datos, aplicaciones empresariales y servicios web. Estos componentes se pueden personalizar y combinar para adaptarse a las necesidades específicas de cada proyecto.

 

______________

Pentaho Data Integration (PDI) es una herramienta de integración de datos open-source que permite la conexión, la transformación y la integración de datos entre diferentes sistemas. Utiliza una interfaz gráfica de usuario para diseñar flujos de trabajo de integración de datos, conocida como Spoon, que facilita la creación de tareas de integración de datos para usuarios sin experiencia en programación.Qué es Pentaho Data Integration (PDI) y para qué sirve?

PDI tiene una amplia gama de componentes preconstruidos, llamados transformaciones y tareas, que se pueden utilizar para conectarse a diferentes fuentes de datos, como bases de datos, aplicaciones empresariales y servicios web. Estos componentes se pueden personalizar y combinar para adaptarse a las necesidades específicas de cada proyecto. También cuenta con herramientas para la limpieza y análisis de datos, así como para la generación de informes y la creación de dashboards.

PDI se utiliza en conjunto con el resto de herramientas de la suite Pentaho, como #Pentaho Report Designer y Pentaho Analyzer, para crear soluciones completas de Business Intelligence.

______________

Apache NiFi es una plataforma de flujo de datos open-source que permite la captura, flujo, transformación y distribución de datos a través de una interfaz gráfica de usuario fácil de usar. Es una herramienta altamente escalable y escalable que se puede utilizar para automatizar y optimizar los flujos de trabajo de datos en una variedad de entornos, desde pequeñas aplicaciones hasta implementaciones de gran escala.

Tus datos se cambian de casa? Apache NiFi te ayuda con la mudanza - Future Space S.A.

NiFi utiliza una arquitectura basada en flujos para organizar y controlar los datos, lo que permite a los usuarios crear flujos de trabajo de integración de datos mediante la arrastrado y soltado de componentes preconstruidos en una interfaz gráfica de usuario. Estos componentes, conocidos como procesadores, se pueden utilizar para realizar tareas como la captura de datos, la transformación de datos, la validación de datos y la distribución de datos a diferentes destinos.

#NiFi también cuenta con características avanzadas, como la capacidad de manejar y procesar datos en tiempo real, la seguridad y el control de acceso, y la monitorización y la gestión de flujos de trabajo. También tiene una integración con otras herramientas y tecnologías de big data, como Apache #Kafka, Apache #Storm y Apache #Hadoop.

Y que hay de los serverless, los que son ejecutados en las #cloud?

Azure Data Factory (ADF) es una plataforma de integración de datos en la nube de Microsoft que permite la conexión, la transformación y la integración de datos entre diferentes sistemas. Es un servicio en la nube que se ejecuta en Microsoft Azure y se utiliza para automatizar los flujos de trabajo de integración de datos.

ADF utiliza una interfaz gráfica de usuario para diseñar flujos de trabajo de integración de datos, llamados “pipelines”, que se componen de diferentes “actividades” que representan tareas específicas, como la copia de datos, la transformación y el procesamiento. Estas actividades se pueden utilizar para conectarse a diferentes fuentes de datos, como bases de datos, aplicaciones empresariales y servicios web, y para copiar y mover datos entre estos sistemas.

ADF también cuenta con herramientas para la automatización de tareas, como la planificación de trabajos y la generación de informes, y cuenta con integración con otras herramientas y tecnologías de Microsoft Azure, como #Azure Data Lake Storage, Azure SQL Data Warehouse y #PowerBI.

Ademas, ADF tiene la capacidad de escalar automáticamente para manejar grandes volúmenes de datos y también cuenta con una variedad de opciones de seguridad y cumplimiento.

______________

AWS Glue es una plataforma de integración de datos en la nube de Amazon Web Services (AWS) que permite la conexión, la transformación y la integración de datos entre diferentes sistemas. Es un servicio en la nube que se ejecuta en AWS y se utiliza para automatizar los flujos de trabajo de integración de datos.

AWS #Glue ofrece una interfaz gráfica de usuario para diseñar flujos de trabajo de integración de datos, llamados “jobs”, que se componen de diferentes “tareas” que representan tareas específicas, como la copia de datos, la transformación y el procesamiento. Estas tareas se pueden utilizar para conectarse a diferentes fuentes de datos, como bases de datos, aplicaciones empresariales y servicios web, y para copiar y mover datos entre estos sistemas.

AWS Glue también cuenta con herramientas para la automatización de tareas, como la planificación de trabajos y la generación de informes, y cuenta con integración con otras herramientas y tecnologías de AWS, como Amazon S3, Amazon Redshift y Amazon Athena.

Ademas, AWS Glue cuenta con un catálogo de metadatos, que permite a los usuarios registrar y gestionar información sobre sus datos, como estructura, relaciones y calidad de los datos. También tiene la capacidad de escalar automáticamente para manejar grandes volúmenes de datos y cuenta con opciones de seguridad y cumplimiento. Asimismo, AWS tiene otro servicio que se llama #DataPipeline.

AWS Data Pipeline es un servicio de #Amazon Web Services (#AWS) que permite automatizar la transferencia y la transformación de datos entre diferentes sistemas de almacenamiento y procesamiento de datos. Es un servicio en la nube que se ejecuta en AWS y se utiliza para crear flujos de trabajo de integración de datos y automatizar tareas relacionadas con la gestión de datos.

Con AWS Data Pipeline, los usuarios pueden crear flujos de trabajo de integración de datos mediante la definición de “tareas” y “relaciones” entre ellas. Cada tarea representa una actividad específica, como la copia de datos desde una fuente a un destino, la ejecución de una transformación o la ejecución de un script. Las relaciones entre las tareas definen el orden en que deben ejecutarse las tareas.

AWS Data Pipeline también cuenta con herramientas para la planificación automatizada de tareas, como la programación de trabajos y la generación de informes, y cuenta con integración con otras herramientas y tecnologías de AWS, como Amazon #S3, Amazon #RDS y Amazon EMR.

Ademas, AWS Data Pipeline tiene la capacidad de escalar automáticamente para manejar grandes volúmenes de datos y cuenta con opciones de seguridad y cumplimiento. También permite a los usuarios monitorear y supervisar el progreso de los flujos de trabajo y detectar y solucionar problemas de manera eficiente.

______________

Google Cloud Dataflow es una plataforma de procesamiento de datos en la nube de #Google Cloud Platform (#GCP) que permite la ejecución de tareas de procesamiento y transformación de datos a gran escala. Es un servicio en la nube que se ejecuta en GCP y se utiliza para crear flujos de trabajo de integración de datos y automatizar tareas relacionadas con la gestión de datos.

Con Cloud #Dataflow, los usuarios pueden crear flujos de trabajo de procesamiento de datos mediante la definición de “tareas” y “relaciones” entre ellas. Cada tarea representa una actividad específica, como la lectura de datos desde una fuente, la ejecución de una transformación, la escritura de datos en un destino. Las relaciones entre las tareas definen el orden en que deben ejecutarse las tareas.

Dataflow permite a los usuarios crear flujos de trabajo utilizando un lenguaje de programación #Java o #Python, y utiliza un modelo de programación de tuberías y filtros para procesar los datos. Ademas, Dataflow es escalable y maneja de manera automática la distribución y el balanceo de carga para procesar grandes volúmenes de datos.

Dataflow también cuenta con herramientas para la planificación automatizada de tareas, como la programación de trabajos y la generación de informes, y cuenta con integración con otras herramientas y tecnologías de GCP, como #BigQuery, Cloud Storage, Cloud Pub/Sub.

Esperamos que esta nota haya sido de interés, y si tienes dudas puedes ponerte en contacto con nosotros.

[popup_anything id=”2076″]

 

 

Categories
54cuatro

Herramientas para modelar Arquitecturas Empresariales

Quienes trabajamos como #EnterpriseArchitect sabemos de la necesidad de documentar lo que vamos creando. Necesitamos herramientas UML para poder bajar a detalle y crear un esquema visual de lo que luego se convertirá en un producto.

¿Qué es #UML?

Esquema de UML

UML es una técnica para la especificación sistemas en todas sus fases, un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño.

Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory.

¿Cuales son las herramientas de UML?

Existen algunas herramientas tradicionalmente usadas para este tipo de trabajos. Tradicionalmente el #Visio de #Microsoft es de las más referenciadas.

En la actualidad existen muchas nuevas herramientas, algunas web, algunas open source, que permiten realizar el modelo de Arquitecturas Aplicativas o de IT en general.

El gran auge de la #nube, creó un sinfín de nuevas herramientas de modelado, algunas específicas para cada nube, como el caso de Cloud Craft que permite crear modelos basados en tecnología #AWS, y que además permite conectarse a la calculadora de #Amazon para realizar el presupuesto de lo que está definiendo.

Visual cloud designer
Captura de Cloud Craft

Sin dudas es una herramienta súper potente. Siguiendo dentro de la misma familia, existen algunas como Cloud Skew o Hava que nos permiten realizar el diseño no solo para AWS sino también para #Azure o #GCP.

Modelando en la web

No podemos dejar pasar por alto herramientas de mucha utilidad como LucidChart o Draw.io (ahora renombrada como Diagrams.net), que no solo son de utilidad para Arquitectos, sino para generar todo tipo de gráficos anidados con cierta lógica como Flujos de Procesos u Organigramas, como para mencionar algunos ejemplos.

Nuestra preferida: Archimate

Nuestra preferida es sin dudas #Archimate. Es quizás la herramienta hecha por y para Arquitectos Empresariales o Enterprise Architects, bajo el estándar abierto propuesto por Open Group.

Archi
Captura de Archimate

Archimate es una herramienta #OpenSource, que puede ser usada en #Windows, #Linux y #Mac, y que puede ser descargada desde la web archimatetool.com. Permite a los usuarios de esta tool, crear modelos basados en frameworks de arquitectura como #TOGAF. Dentro de una misma aplicación se pueden crear flujos de negocios, modelos de planificación de tipo Mind Mapping, modelos de interrelación aplicativa, y hasta planificaciones basadas en #Agile.

Sin dudas es la elegida por nuestro equipo, y la que recomendamos para llevar a cabo las tareas de planificación inherentes a un arquitecto.

¿Y tu equipo, qué herramienta utiliza?

[popup_anything id=”2076″]
Categories
54cuatro

Patrones de Arquitectura Serverless

Acerca de la arquitectura Sin Servidor

Hace un tiempo hicimos una entrada respecto a patrones de arquitectura para microservicios, la cual tuvo gran repercución, motivo por el cual traemos esta entrada referente a la arquitectura serverless.

Cuando hablamos de arquitectura serverless o “sin servidor” nos referimos a diseños de aplicaciones que utilizan un Backend como Servicio de terceros (ej, Auth0) o que incluyen código propio que se ejecuta en contenedores efímeros administrados por un tercero, en plataforma que denominamos “funciones como servicio” (FaaS).

Lógicamente estos contenedores son auto-administrados por el proveedor, en general Cloud Providers, pero de cara al cliente una plataforma serverless evita tener que gestionar infraestructura en su formato tradicional.

Existen aplicaciones para lograr correr Serverless on-premise, proyectos como Fission o Kubeless, permiten armar la infraestructura sobre Kubernetes; pero el gran crecimiento de estas soluciones esta dado por los proveedores como #AWS, #Azure y #GCP.

FaaS que delega un parte de la arquitectura en Backend como Servicio (#BaaS)

Este tipo de arquitectura en gran parte esta siendo impulsada por los microservicios, permitiendo generar una reduccion significativa de las ingenierias, delegando muchas partes de la arquitectura en terceros. Por ejemplo:

En el gráfico podemos observar un sistema típico de autorización/autenticación de un sitio web en un formato tradicional con los usuarios generados en la misma base de datos operativa, contra un sistema que delega la autorización/autenticación en un sistema de un tercero (#AWS #Cognito en el ejemplo). En el ejemplo tenemos 2 patrones. La validación de usuarios pasa a ser un microservicio, y su funcionamiento es completamente delegado a un tercero que nos brinda su backend como un servicio. En lineas generales la arquitectura de microservicios requiere de la creación de un #API gateway.

Pero sigamos avanzando y veamos otro formato de #FaaS o Serverless.

El otro formato al que se suele hacer referencia cuando se menciona #serverless se trata de ejecutar código backend sin administrar servidores y las corridas se efectúan durante un periodo de tiempo. En este caso, el código que uno realiza, es ejecutado por una plataforma de terceros, básicamente cargamos el código de nuestra función al proveedor, y el proveedor hace todo lo necesario para aprovisionar recursos, instanciar VM, crear #containers, administrar procesos, y ademas de gestionar la performance y asegurar los servicios. Las #funciones en FaaS generalmente se activan mediante tipos de eventos. Ej: recibir una petición http, detectar un objeto en un storage, tareas programadas manualmente, mensajes (tipo MQ), etc.

Functions as a Service: Evolution, Use Cases, and Getting Started | Oracle Developers Blog

Precaución con el concepto de Stateless o Sin estado

Se suele decir que las FaaS son #stateless o “sin estado”. Este concepto hace referencia a que al ser código que se ejecuta de forma efímera, no existe almacenamiento disponible, de manera que cualquier función que requiera mantener persistencia debe externalizar la persistencia fuera de instancia FaaS. En Stateless cada operación se realiza como si se está haciendo por primera vez. Cuando una función requiere persistencia debemos acudir a capas adicionales de infraestructura como bases de datos de caché, bases de datos relacionales y/o storages de archivos y objetos y de esa forma pasamos a ser #stateful, lo que significa que se controla la historia de cada transacción pasada y que ellas pueden pueden afectar a la transacción actual.

Tiempo de ejecución

Otro concepto importante cuando hablamos de serverless tiene que ver con el tiempo de ejecución de las funciones. En la arquitectura sin servidor, las funciones suelen estar concatenadas y orquestadas donde cada tarea es dependiente de otra, y esto hace que si alguna se demora o falle, pueda afectar toda la sincronización configurada. Este motivo es suficiente para determinar que funciones de larga duración no son apropiadas en este modelo.

How to Reduce Website Execution Time?

En linea con esto, existe otro concepto llamado “arranque en frío” y que tiene que ver con el nivel de respuesta de una función ante su desencadenador.

Como mencionamos, el desencadenador o trigger es lo que dispara la ejecución de una función y la función luego se ejecuta durante un periodo de tiempo determinado, esto hace que aplicaciones con muchas lineas de código, que llaman librerías, o cualquier motivo que genere que el inicio sea “pesado”, no sean recomendables para entornos FaaS.

Ventajas y Desventajas de FaaS

Sin dudas adoptar serverless es algo que esta de moda, y que trae sus grandes ventajas. En la parte de arriba hemos recorrido grandes ventajas y hemos detectado situaciones donde no es conveniente usar funciones. Pero como resumen podemos resaltar que trae grandes ventajas a nivel costos, dando como resultado una fuerte reducción de los mismos. Adicionalmente permite optimizar ejecuciones y simplificar gran parte de la administración de infraestructura requerida para ejecutar código.

En contrapartida, la arquitectura serverless requieren de cierta maduración por parte de los desarrolladores (y sus productos) ya que todo el despliegue se debe hacer bajo modelos CI/CD en lo que actualmente se esta dando a conocer como #NoOps (voy a patentar el termino YA*OPS, yet another * ops :)) donde se busca poder ir a producción sin depender de un equipo de Operaciones.

Y finalmente, es importante mencionar que al subir código a proveedores de nube se genera un alto nivel de dependencia sobre ellos, algo poco recomendado claramente.

Patrones de arquitectura

Es el titulo de la nota, pero hasta ahora no hicimos foco sobre patrones. Los patrones de arquitectura serverless aun no tiene un marco definido. Lo que se viene delimitando como mejores practicas tiene que ver con temas a considerar previo a crear una plataforma serverless. Por ejemplo:

  • ¿Cuantas funciones se crearán?
  • ¿Que tan grandes o pesadas serán?
  • ¿Como se orquestarán las funciones?
  • ¿Cuales serán los disparadores de cada función?

Gran parte de la estrategia serverless viene adoptada de las arquitecturas de microservicios y de eventos; y en gran parte los conceptos ‘Event Driven’ y ‘API Driven’ conforman el núcleo de arquitecturas serverless. Y esto hace que también debamos preguntarnos:

¿Como generamos una arquitectura híbrida que considere API, Funciones, PaaS, IaaS, etc.?

La CNCF y los proveedores de nube vienen trabajando a gran velocidad para responder estas consultas y establecer un marco arquitectónico a considerar, algo que será muy bienvenido por todos, ya que nos permitirá tener referencias por ejemplo para lograr neutralidad sobre dónde y cómo implementar nuestras apps sin caer indefectiblemente en el ‘vendor lockin’ o como generar una estrategia multicloud en arquitecturas FaaS.

Conclusión

Durante la nota explicamos ventajas, desventajas y consideraciones en cuanto a montar servicios corriendo serverless. Sin dudas es una tendencia que cada día crece mas y se encuentran nuevos beneficios. En nuestra consideración permite crear grandes productos, pero siempre hablando de productos digitales nuevos, no creemos que refactorizar aplicaciones existentes y/o migrar a serverless sea hoy una estrategia viable. No es imposible, pero si algo arriesgado. La recomendación es comenzar con piezas pequeñas, integraciones y ejecuciones controladas. Para otro tipo de aplicaciones mas complejas, los esquemas de microservicios sobre contenedores son una buena alternativa a la que incluso aun les queda mucho por recorrer.

Si esta pensando en trabajar con serverless y necesita ayuda, escribanos desde el siguiente formulario:
[popup_anything id=”2076″]
Categories
54cuatro

Transitando la adopción de arquitecturas serverless

La tecnología serverless fue la que mayor crecimiento expone desde el 2018 hacia hoy. #AWS y luego #Azure fueron dos grandes promotores de la tecnología #serverless. Al dia de hoy existen múltiples alternativas, incluso para correr serverless sobre on-premise.

¿De dónde viene la tecnología sin servidor?

En primer lugar, tenemos que hablar de Virtualizacion. La virtualización de servidores fue el paso inicial, que se basaba en correr múltiples servidores en un mismo hipervisor. Con el avance de la nube publica, las empresas utilizaron #IaaS (infraestructura como servicio), que básicamente es arrendar servidores y mover la carga de la infraestructura a la nube, pero los equipos aún tenían que lidiar con la configuración del servidor. Mas tarde apareció en escena PaaS (Plataforma como servicio). Los proveedores de #PaaS ofrecían una pila de aplicaciones más completa, como sistemas operativos y bases de datos para ejecutarse en la nube y ser administrados por el proveedor. Pero eso no fue suficiente. Luego surgió la tendencia de crear contenedores, una tendencia que sigue en alza, pero que significa de todas formas llevar a cabo configuraciones.

#Serverless o #FaaS (función como servicio) representa un nuevo enfoque para el desarrollo de aplicaciones. En pocas palabras, FaaS es una forma de computación sin servidor que utiliza una infraestructura completamente administrada por un proveedor para cargar funciones y ejecutarlas mediante “pago por solicitud”, y logrando que los desarrolladores y equipos de operaciones se abstraigan totalmente de las instalaciones de sistemas operativos, servidores de aplicaciones, librerías, etc.

Arquitectura Serverless

La arquitectura “sin servidor” aplica a una capa de servicios, por tanto, los diseños de arquitectura deben contemplar las capas de datos e integración como parte de la misma. En líneas generales, las capas de presentación (web, mobile) y las de aplicaciones son las mas factibles de llevar a modelos serverless, con los siguientes beneficios:

Menores costos y escalabilidad. En comparación con el enfoque tradicional, reduce los costos de operaciones y mantenimiento del servidor. En comparación con otros tipos de computación en la nube, la mayoría de los proveedores de FaaS trabajan con el modelo de precios de pago por solicitud. Esto significa que solo paga por el tiempo que se invocó una función y por la cantidad de invocaciones.

Capacity planning. Puede asignar una cierta cantidad de memoria y CPU para una función, y escalarla según sea necesario hacia arriba y hacia abajo. Incluso apagarse apagarse cuando no sea necesaria.

Desarrollo e implementación más rápidos. En lugar de escribir una estructura monolítica, FaaS ofrece una alternativa más flexible. Los desarrolladores pueden escribir código para un conjunto de funciones, en lugar de toda la aplicación monolítica, y cargar bits de código en el servidor. Eso hace que toda la estructura sea fácil de corregir, actualizar y agregar nuevas funciones.

Proveedores de arquitectura serverless

#AWS es quien introdujo la tecnología con mayor fuerza. #Lambda se convirtió en sinónimo de serverless, manteniendo la posición de producto líder en el mercado con la más amplia gama de servicios disponibles. #Azure Functions fue el siguiente oferente de esta tecnología en la nube, ofreciendo un conjunto de servicios similar a Amazon pero con un enfoque orientado hacia familia de lenguajes y herramientas de #Microsoft.

Luego #Google en #GCP, #IBM, #Oracle, #Huawei lograron implementar soluciones serverless en sus nubes. Todos los proveedores mencionados ofrecen servicios similares, suficientes para lanzar una aplicación en una infraestructura administrada.

En cuanto a la compatibilidad de lenguajes, Azure y Lambda admiten más idiomas que otros proveedores, y en cuanto a performance, no existe una diferencia crítica entre el rendimiento de las FaaS de cada provider.

Como monitorear servicios sin-servidor

El monitoreo es necesario para controlar las aplicaciones que corran en formato serverless, teniendo en cuenta ademas que toda la infraestructura es administrada por un proveedor. Entonces, para ver qué sucede exactamente con su aplicación y aplicar métricas, cada servicio tiene que ofrecer herramientas de monitoreo / registro. Esto le permite una descripción general de los recursos asignados y utilizados, detectar errores, monitorear registros, etc. Un factor fundamental a monitorear tiene que ver con la concurrencia, entendiendo por concurrencia a la ejecución paralela de diferentes funciones en un período de tiempo determinado, esto permite determinar la tasa simultaneidad que tolera cada aplicación, y que viene determinada por configuraciones a realizar en el proveedor del servicio FaaS.

¿Puedo tener Serverless en mi datacenter?

Si. Por ejemplo Kubernetes ademas de funcionar como herramienta para automatizar la implementación, la administración y el escalado de aplicaciones en contenedores, tiene un marco nativo sin servidor para la implementación de código llamado Kubeless.

Apache OpenWhisk es otra plataforma de código abierto que ejecuta funciones, pero administra la infraestructura, los servidores y el escalado mediante contenedores Docker. Tambien existe una herramienta open source llamada Fn project. Es una plataforma sin servidor de código abierto que se puede ejecutar en cualquier lugar, en la nube o en on premise.

En cuanto a herramientas comerciales, #RedHat posee #Openshift Serverless, una herramienta serverless de nivel empresarial que brinda portabilidad y uniformidad a todos los entornos híbridos y multicloud basada en Knative.

Conclusión

La tecnología Serverless permite acceder a una forma de trabajar, con mayor foco en el desarrollo, delegando la administración de la infraestructura a un tercero.

¿Ya habías oído de Serverless? ¿Tu empresa se encuentra en proceso de adopción?

    Please prove you are human by selecting the flag.

    Categories
    54cuatro

    Que es CRISP-DM y como utilizarlo en proyectos de analítica

    ¿Que es CRISP-DM?

    CRISP–DM es una metodología utilizada en proyectos de Data Mining. Es la guía de referencia más utilizada.

    Image for post

    Consta de 6 fases fundamentales para encarar cualquier proyecto de Data Mining.

    1. Comprensión de los requisitos de negocios
    2. Comprensión de los datos disponibles
    3. Preparación de los datos
    4. Modelado
    5. Evaluación
    6. Implementación

    1- Fase de Comprensión de los requisitos de negocios

    En esta fase se realiza el análisis del requerimiento de negocios que buscamos resolver utilizando análisis sobre los datos.

    Es una de las fases mas importantes, si no la mas importante. Establecer el objetivo permite determinar que datos necesitamos, buscar las fuentes y analizar la calidad de los datos disponibles.

    El proceso de adquisición de datos es muy tedioso, dependiendo del problema que intente resolver.

    2- Comprensión de los datos disponibles

    Durante esta fase se identifica que datos tenemos, y como mencionamos, se analiza la calidad de esos datos.

    Se busca comprender si existen faltantes fundamentales, la calidad, las relaciones, y también es donde se efectúan análisis exploratorios hipotéticos. Por ejemplo:

    • Seleccionar columnas importantes
    • Filas de muestreo (prueba de tren dividida, validación cruzada)
    • Crear o derivar nuevas variables compuestas
    • Filtrar datos (filtrar puntos de datos irrelevantes)
    • Fusión de fuentes de datos (agregaciones de datos)
    • Imputar o eliminar valor faltante
    • Decidir si eliminar o mantener el valor atípico

    3- Preparación de los datos

    En esta fase se realiza la preparación de los datos para adaptarlos a las técnicas de Data Mining que se utilicen posteriormente, tales como técnicas de visualización de datos, de búsqueda de relaciones entre variables u otras medidas para exploración de los datos.

    Durante esta etapa se va a seleccionar la técnica de modelado mas apropiada, junto con la limpieza de datos, generación de variables adicionales, integración de diferentes orígenes de datos y los cambios de formato que sean necesarios.

    4- Modelado

    Durante el modelado, se busca establecer modelos de análisis basados en las técnicas de mining que son apropiadas al objetivo de negocios con los datos disponibles que tenemos. Si el objetivo conlleva una solución que tiene que ver con técnicas de Clasificación, podemos elegir entre Arboles de Decision, K-Near, CBR u otros. Si lo que buscamos resolver tiene que ver con Predicciones, realizaremos análisis basados en Regresiones.

    Una vez determinado el modelo, se construye y adicionalmente se debe generar un
    procedimiento destinado a probar la calidad y validez del mismo. Por eso pasamos a la siguiente fase, Evaluación.

    5- Evaluación

    Durante esta fase, se realizan 2 evaluaciones. Por un lado se evalúa el modelo, teniendo en cuenta si se cumplen los objetivos de negocios planteados. Para ello se utilizan técnicas para determinar la performance de modelo, y en base a eso, ajustar las variables que mejoren su rendimiento.

    Por otro lado, se evalúa que las evaluaciones realizadas por los modelos probados, son de valor para el negocio. Durante esta parte de la evaluación, es necesario trabajar con gente que pueda interpretar si los datos son fiables o es aconsejable probar otros modelos.

    6- Implementación

    En la fase anterior, un analista de negocio nos dio feedback sobre los resultados obtenidos. Si los datos no fueran fiables, volveríamos a fases anteriores, para ajustar el proceso.
    Pero si los datos dieran resultados valiosos, y es donde esta sexta fase, se considera la fase de implantación del conocimiento obtenido para que sea transformado en acciones dentro del proceso de negocio, por medio de accionables estratégicos (campañas de marketing, de ventas, publicitarias, ofertas, mejores precios, etc etc etc).

    Detalles a tener en cuenta

    #CRISP-DM cumple con 6 fases, las cuales no son estáticas ni estancas. Este proceso es dinamico y se debe considerar un proceso de revisión del proceso entero de #datamining, para poder identificar datos, variables, relaciones y cualquier tipo de elemento que pueda ser mejorado.

    En la actualidad existen muchas ofertas de servicios basados en #MachineLearning, pero este tipo de análisis no nacieron con los servicios #cloud. Si es importante destacar que en la actualidad servicios como #Azure, #AWS y #GCP cuentan con herramientas de analítica que facilitan la recolección, limpieza y explotación de los datos, pero frameworks como #CRISP existen hace muchos años y es de vital importancia hacer uso de sus bondades, y aprovechar su ayuda para administrar los datos de una manera más estructurada.

    Video Resumen

    [popup_anything id=”2076″]

    Categories
    54cuatro

    ¿Y ahora MLOPS?

    Quienes nos siguen dirán, ¿Otro nuevo Ops en familia? Y si, tenemos que contarles sobre #MLOPS.

    Repasemos. #DevOps conjuga la unión de los equipos de Desarrollo con Operaciones. #DataOps va acerca de la integración de datos en pos de soluciones analíticas. #GitOps nos ayuda a con el despliegue continuo sobre plataformas de contenedores. Y ahora nos toca describir MLOPS.

    ¿Que es MLOPS?

    El nombre viene de la conjugación de Machine Learning y Operaciones. Y su filosofía gira en torno a lo mismo que sus familiares *Ops, la de generar un espacio colaborativo, en este caso entre Científicos de Datos y Operaciones. Es importante destacar que hace un tiempo se puso de moda el termino #AIOPS, pero esta mas orientado a una implementación de Inteligencia Artificial a las operaciones de TI, de manera que podria ser confundible con MLOPS.

    Empecemos a descubrir MLOPS.

    MLOps Principles

    ¿Que soluciona MLOPS?

    MLOps es un descendiente directo de DevOps, y continuando con el éxito busca resolver la integración de los equipos de operaciones (en este caso quienes operan los datos) con aquellos que requieren de esa data para generar informacion de valor.

    MLOps incorpora al juego a los científicos de datos, quienes requieren obtener conjuntos de datos de manera automatizada desde donde poder desarrollar sus modelos analíticos.

    ¿MLOPS requiere de un Pipeline?

    Correcto, MLOPS tiene su propio concepto de Pipeline, solo que el CI/CD, esta orientado a integraciones de datos, y junto con ello, capacidades de gobernanza, transparencia y protección de la informacion.

    • En CI ademas de probar y validar código y componentes, se deben validar datos, esquemas y modelos.
    • En CD ademas de desplegar un paquete, debe implementar todo un servicio de manera automática.

    En resumidas fases podriamos mencionar que MLOPS requiere de 4 pasos fundamentales:

    • Ingestar datos hacia un almacenamiento.
    • Procesar los datos almacenados.
    • Entregar esos datos para ser entrenados dentro de modelos de #MachineLearning.
    • Entregar el output del modelo, dependiendo el caso de negocio requerido.
    Gartner on ML pipeline
    Esquema MLOPS propuesto por Gartner

    ¿Como comienzo mi camino hacia MLOPS?

    Es importante destacar que la comunidad que impulsa MLOPS crece dia a dia. Y ese crecimiento lleva a tener mas opciones que simplifican la adopción de MLOPS. Tanto #AWS, #GCP, #Azure, #IBM y otros proveedores tienen su propio stack tecnológico para hacer frente a una implementación de MLOPS, y como todo, no existe un método único, pero si buenas practicas recomendadas a seguir.

    Para empezar, debemos crear una cultura de automatización.

    El objetivo de MLOps es automatizar los pasos completos del flujo de trabajo de ML sin intervención manual. A partir de ello debemos dividir las tareas en fases que al final de la historia se ejecuten como un pipeline. Estas tareas son:

    1. Adquirir los datos desde las fuentes que identifiquemos. Y dentro de esta fase de adquisición vamos a Catalogar los Datos, Ingestarlos a nuestro almacenamiento, Procesarlos para generar nuestra data correcta, y finalmente Entregarlos para su consumo.
    2. Desarrollar los modelos. En esta fase (quizás la mas importante) un científico de datos generara interacciones con distintos modelos analíticos, validando la data recibida, e identificando la performance de los análisis. En caso de que la data recibida no sea suficiente o de la calidad esperada, el pipeline debe ser reajustado en el paso 1. Pero si los modelos tienen buenos rendimientos se pasara a la siguiente fase.
    3. Despliegue de los modelos. Como mencionamos anteriormente, si un modelo tiene buenos rendimientos y sus outputs son confiables, esta listo para ser pasado a producción. Tener un modelo productivo permite integrarlo a nuestro software, dejar una API para consultas, alimentar un sistema, etc. Pero atención, el modelo requiere de cuidados, y es por eso que existe una ultima etapa.
    4. Monitoreo de modelos. Como vamos a tener corriendo todo de forma automatizada, es importante monitorear como es la performance de los modelos. Cualquier desvio en la cantidad y/o calidad de los datos que se reciben pueden alterar el funcionamiento de nuestro desarrollo. Y es por eso que en un modelo MLOPS, vamos a determinar un control para conseguir que nuestro pipeline siempre asegura la entrega de información de valor para el negocio.

    Conclusión final

    Para ejecutar un proyecto exitoso basado en ciencia de datos es imprescindible implementar MLOps y para ello se debe llevar a cabo una orquestación de las herramientas tecnológicas con las habilidades para integrarlas.

    Consultas?

    [popup_anything id=”2076″]
    54cuatro © 2024. All rights reserved.