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

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″]
Categories
54cuatro

El testing dentro de CI/CD

Desde antes de la fiebre #DevOps que sabemos que había que automatizar las pruebas de software, pero no se hizo. Los equipos de desarrollo fueron haciendo mayor énfasis en las pruebas de interfaz de usuario que en pruebas unitarias, y por consiguiente se fue deformando el enfoque propuesto por Mike Cohn, denominada ‘Pirámide Ágil de Automatización de Testing’.

test automation strategy
Agile test automation pyramid – Mike Cohn

Esta pirámide es quizás la mejor definición de como deberíamos ejecutar las pruebas, y concentrarnos en la interfaz de usuario genera un patrón basado en Detectar Errores, cuando lo que debiéramos hacer es Prevenir Errores.

Pruebas unitarias

Esto tipo de testing es el que se realiza en la etapa de desarrollo, ejecutando pruebas unitarias después de cada compilación se consiguen datos específicos para un programador; ej: hay un error y está en la línea 1143.

Además habitualmente las pruebas unitarias se realizan en el mismo lenguaje que la pieza de software de manera que los programadores suelen mantener una cierta comodidad escribiendo pruebas.  

Capa de Integración

En esta capa, se suele probar la integración de todos los componentes. Es donde se controla que todos los componentes funcionen correctamente y donde se busca comprobar que la lógica del software se encuentra alineada al requerimiento. Estas pruebas no solo aplicación a arquitecturas orientadas a servicios (SOA) sino también a variantes modernas de microservicios. En el caso de pruebas de API, necesita saber cuándo fallan sus API, por qué fallaron y necesita un circuito de retroalimentación ajustado para alertarlo lo antes posible. Es importante el testing en esta capa ya que si bien el end-to-end de las aplicaciones están compuestas de varios servicios que se concatenan entre si, hay muchos casos de prueba que deben invocarse de manera individual dado que no todos pueden ser ejecutados a través de la interfaz de usuario.

Pruebas de Interfaz de Usuario

Llegamos al tope de la pirámide. Y es justamente el tope de la pirámide porque este tipo de pruebas deben realizarse lo menos posible. Por motivos varios, son costosas, difíciles de preparar y requieren mucho tiempo. Ademas de que suelen salir muchos falsos negativos y falsos positivos. Pero de todas modas no debe evitarse esta etapa, dado que probando la interfaz de usuario se logra una prueba de extremo a extremo, para verificar el sistema en su totalidad. 

El equipo de desarrollo de Google sugiere que las pruebas deben ser realizadas 70% de pruebas unitarias, 20% de pruebas de integración y 10% en la capa superior.

Integrando el testing en un modelo CI/CD

Which one is right for you: Waterfall or Agile? |

Recordemos que CI/CD es un pilar de #DevOps que busca desplegar aplicaciones de software por medio de la automatización; y como es bien sabido que el #testing es parte de todo esto, debemos tener integradas las pruebas para poder seguir con el circulo virtuoso que propone DevOps.

Integrar el testing bajo el concepto de “Testing Continuo” permite detectar errores de forma temprana y por ende resolverlos con gran rapidez.

Algunos test que son potencialmente automatizables son las pruebas de regresión, funcionales, de integración y de rendimiento. Algunas herramientas nos permiten facilitar las tareas de automatización de testing, aunque no menos importante es encontrar que será automatizado, y también orquestar inteligentemente las pruebas.

Herramientas para Pruebas Continuas

  • #Katalon. Esta herramienta ofrece una plataforma integral para realizar pruebas automatizadas para interfaz de usuario web, servicios web, servicios API y dispositivos móviles.
  • #Travis CI. Travis CI es un servicio de integración continua alojado que se utiliza para crear y probar proyectos de software alojados en GitHub y Bitbucket.
  • #Selenium es una herramienta de prueba compatible con la mayoría de los navegadores convencionales, como Chrome, Firefox, Safari e Internet Explorer.
  • #Azure Test Plan. En lo que refiere a ambientes #cloud, #Microsoft tiene una gran oferta de soluciones dentro de su suite Azure DevOps, y en este caso un kit de herramientas de pruebas exploratorias y manuales con una interfaz intuitiva e integrada.

Conclusión

Este tema da para largo y en próximas entradas seguiremos explorando el testing en el marco de DevOps, haciendo foco en Microservicios, API e incluso en Data.

El testing como parte de una cadena CI/CD es muy beneficioso, pero también pueden muy desafiante. Es necesario tener un buen plan de testing tradicional antes de incorporar este procedimiento de prueba.

Posterior a tener un buen marco de pruebas es recomendable trabajar en las estrategias de incorporación del flujo de pruebas al pipeline.

Gracias por leernos!


[popup_anything id=”2076″]
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

Gestionando los legados

No esta mas el que lo desarrolló. Esta hace muchos años y nadie sabe como funciona. No tenemos soporte del proveedor.

Te parecen conocidas estas frases? Son algunas de las muchas que se escuchan dia a dia en las organizaciones ante la imposibilidad de actualizar sus sistemas legados.

¿Qué son los legados?

Podriamos definirlos como esos programas que nadie quiere tocar, nadie sabe quién lo escribió y que absolutamente nadie quiere correr el riesgo de reemplazarlo.

Podemos citar muchos casos de software legado que actualmente es de vital importancia en las organizaciones, por ejemplo los core banking o tasadores de Telcos.

¿Y porque nos encontramos con esta situación? Principalmente estas situaciones se dan cuando un software pierde su ciclo de actualización constante, y ante esa situación se comienza a perder conocimiento, se empiezan a ir los recursos claves que lo mantienen y ante esa situación cada dia se aísla mas del dia a dia. Para evitar que un software quede obsoleto, se requiere mejorarlo gradualmente y llevarlo a estándares de forma continua.

¿Cómo gestionar una aplicaciones legacy?

Reescribir el código (#rewrite): esta opción es compleja, porque básicamente se basa en rearmar el programa con las mismas funcionalidades, pero con tecnología y practicas apropiadas al momento actual. La mayor complejidad de esto es tener que mantener dos sistemas similares funcionando, y posteriormente ir pasando “carga” del viejo al nuevo o directamente volcar todo el trafico de un sistema a otro en un formato “big bang”.

Refactorizar el código (#refactor): esta opción se basa en reemplazar las funcionalidades del sistema antiguo, gradualmente. Esta estrategia consiste en relevar cada función, interface, clase, modulo, etc del sistema antiguo y construir una nueva pieza de software de ese elemento particular. Durante el refactoring, es posible detectar funcionalidades que ya no son necesarias, y a ellas se las deja “morir por inanición”.


¿Reescribir o Refactorizar?

Lógicamente es necesario analizar cada situación. No es lo mismo Reescribir todo un Core Bancario, que Refactorizar una aplicación para que deje de usar #MySQL para usar #MongoDB.

Se debe tener en claro cual es el aporte de valor de cada estrategia de cara al negocio. Posteriormente es bueno efectuar un assessment que permita situar el nivel de complejidad de la operatoria.

  • Relevamiento del software, interfaces, integraciones, etc.
  • Identificar la complejidad de las tareas
  • Identificar los riesgos
  • Definir con que enfoque se planeará la modernización de aplicaciones, apostando a disminuir el riesgo y los costos.

Planeando la nueva arquitectura

¿Estamos rediseñando una aplicación monolítica? ¿Es SOA? ¿Es Rest? ¿Crearemos #API? ¿Vamos a la nube? ¿Adoptaremos microservicios? ¿Usamos contenedores? ¿#Serverless, eso que es?

No es lo mismo pasar de .NET a .NET Core, que modificar un desarrollo en Cobol.

Es muy importante definir cual será el diseño futuro que “absorberá” a nuestro legado. Y de esa forma planificar cuales serán los pasos apropiados. Si de una app de baja complejidad tipo monolito vamos a ir a un esquema de #microservicios o #serverless es una buena oportunidad para reescribir desde cero. Pero si el sistema heredado en cuestión es el core de su negocios, no puede darse el lujo de correr riesgos innecesarios, y para este caso, es preferible optar por una refactorización progresiva. De igual forma, si las personas que hicieron originalmente al sistema legado ya no están en la compañía, tampoco tiene sentido refactorizar y será más fácil reescribirlo.

What is a Mainframe Computer? - A Guide from IBM Mainframes

Como vemos, no existe una tabla que resuelva las decisiones mágicamente. A veces, en ciertas oportunidades la refactorización de código es la mejor opción, por seguridad o por practicidad. Pero la refactorización de código en otros casos puede brindar una ganancia rápida en términos de capacidad de mantenimiento y rendimiento, construyendo nuevamente desde 0.

Existe un tercer modelo que podemos denominar Rehosting, y consiste en realizar un proceso llamado ‘Lift & Shift‘. Esta actividad tiene como finalidad levantar una aplicación legada y moverla a un nuevo entorno, ya sea #cloud, o #container, o #serverless. Esta opción es muy interesante para mover aplicaciones sin tener que esforzarse mucho en hacer una reescritura sustancial, en líneas generales, este tipo de procesos son de mucha utilidad para reducir la obsolescencia de hardware, pero como contra, es importante destacar que no tiene el valor que se encuentra en reestructurar la aplicación.

Desde 54cuatro estamos apoyando a las organizaciones a disminuir los riesgos que conllevan estas decisiones, a través de nuestros servicios de consultoría en Arquitectura con profesionales especializados en enfoques la modernización de aplicaciones que tienen en cuenta componentes de plataforma, arquitectura aplicativa y el diseño de API. Necesitas apoyo? Escribinos.

[popup_anything id=”2076″]
Categories
54cuatro

SRE: Observabilidad y Monitoreo

Nota publicada originalmente por el CTO de #54cuatro en Linkedin.

La #observabilidad es una característica dentro de un sistema de control que permite dar con una solución prediseñada a un problema que surja. Dentro del mundo TI, la observabilidad de un sistema permite evaluar resultados para llegar a conclusiones sobre los estados de un recurso.

Si bien han surgido distintos puntos de vista sobre la definición, a partir de la masificación de #DevOps (y #SRE), el crecimiento de las instalaciones #Cloud, el uso intensivo que hacen las plataformas de #bigdata y la adopción de #Contenedores, la observabilidad se volvió una palabra en constante crecimiento.

A diferencia de las actividades de monitoreo tradicionales, donde el objetivo es “observar” el estado, la salud y #performance de #Redes, #Servidores, #Servicios, #Redes, Aplicaciones, etc para luego tomar acciones, la observabilidad podriamos definirla como un componente mas del diseño de una aplicación que permite tener en cuenta todos los elementos de la misma para saber como monitorearlas y operarlas.

Al igual que el análisis de la seguridad en nuevos desarrollos (#DevSecOps), es de esperar que también se realicen los diseños de monitoreo de los componentes en etapas tempranas de la construcción del software y no al momento de la implementación.

Sin ir a mas, en el sitio de SRE de Google, indican que la operación exitosa de un servicio implica una amplia gama de actividades: desarrollar sistemas de monitoreo, capacidad de planificación, responder a incidentes, asegurar que se aborden las causas fundamentales de las interrupciones, y ponen esta pirámide que permite ver los elementos que intervienen para hacer que un servicio sea confiable, desde el más básico hasta el más avanzado.

No hay texto alternativo para esta imagen

Diseñar y desarrollar aplicaciones “observables” permite ser proactivo y prever los posibles puntos de fallas, con el objetivo de lograr rápidas recuperaciones ante fallos y administrar de forma eficiente el capacity planning y junto a ello la performance.

Podemos pensar un sistema observable a partir del control de todas las partes, conociendo como se desarrolló, como estará montado y como se comportará, podremos definir el monitoreo horizontal (servidores, redes, transacciones, logs) y el monitoreo vertical (experiencia de usuario, tracing, debug) mas acorde. El Monitoreo y la Observabilidad son cosas diferentes y también complementarios.

De hecho, el concepto de observabilidad no tiene que estar ligado al incidente. Una aplicación observable puede reportar datos que permitan mejorar la arquitectura, la performance, el escalamiento automático sin la necesidad que haya un perjuicio o incidencia dentro de la plataforma.

Para ir finalizando, podemos decir que debemos de adoptar una estrategia que consista en diseñar aplicaciones observables desde su nacimiento, diseñando de que manera vamos a controlar y monitorear la nueva aplicación, entendiendo que componentes vamos a usar y cuales son las mejores métodos y/o herramientas para respaldas la salud de esas aplicaciones; de allí el nacimiento de grandes conjuntos de tools que funcionan muy bien juntas. Se me vienen a la cabeza soluciones basadas en #ELK, en #Influx o la dupla #Prometheus y #Grafana, básicamente Prometheus recopila datos y métricas de diferentes servicios y los almacena de acuerdo con un identificador único, el nombre de la métrica, y una marca de tiempo (en una base time series) y Grafana se encarga de realizar hermosos dashboards donde mirar dicha información. Toda esta informacion puede ser “cruzada” con aquellos datos adicionales que tengamos configurada en nueva navaja suiza del monitoreo como las experiencias de los usuarios y con toda la correlación de los eventos determinar que todos los servicios de monitoreo estén vivos y saludables.

Video de Monitoreo de Infra

No hay texto alternativo para esta imagen

Video de Monitoreo #Netflow

Como siempre… Gracias por leerme! Hasta la próxima!

[popup_anything id=”2076″]

Categories
54cuatro

Sabes que es #Serverless?

Sabes que es #Serverless? Tiene beneficios para los #desarrolladores, es escalable, pero también necesita de ajustes en el #código para que pueda ser ejecutado como funciones (#FaaS), ademas en muchos casos el código puede quedar ligado a su #cloud provider.

[popup_anything id=”2076″]

Categories
54cuatro

¿Que (y para que) es EDGE Computing?

Nota publicada originalmente en Linkedin

Hace unos días, mientras esperaba en el aeropuerto, escribí una nota #Industria 4.0. Para seguir profundizando en el ecosistema de #I4.0, voy a hacer entradas complementarias para no hacer la entrada original muy larga.

En este caso para escribir sobre #EDGEComputing, o Procesamiento de Borde. Algo fundamental para Industria 4.0 y de lo que se esta hablando mucho.

Edge Computing

Sabemos que la cantidad de dispositivos crece exponencialmente, y junto a ello la cantidad de datos que se generan (y que queremos analizar). Por tal motivo se empieza a hablar cada vez mas de Edge, y de un formato de arquitectura tecnológica donde el procesamiento de la informacion se acerca cada vez mas a los orígenes de los datos (datacenters descentralizados, lineas de producción, almacenes, robots, etc) para brindar una rápida respuesta en pos de obtener informacion de valor de los datos generados. Procesar en origen (o cerca de el) evita transportar los datos a centros de cómputos o proveedores de nube, disminuyendo sustancialmente su tiempo de análisis, realizando la tarea casi en tiempo real. Este es quizás el mayor beneficio, no solo por mejorar el procesamiento, sino también por generar un ahorro significativo del consumo de ancho de banda.

Algunos especialistas pronostican que Edge sera un nuevo modelo de procesamiento, AT&T lo definió como una supercomputadora inalámbrica.

Y es importante destacar que no se trata de elegir si #EDGE o #Cloud. Son ambas. Una arquitectura #IIoT (#Industrial IoT) de alto nivel debe considerar un modelo de que abarque el procesamiento EDGE y Cloud, para unir el mundo de las operaciones tradicionales (OT) con la TI empresarial. Macario Namie de Cisco deja una gran frase en esta nota: Uno de las mejores resultados de conectar “cosas” es el acceso sin bloqueos a datos en tiempo real. Lo siguiente es convertir esos datos en información, y lo que es más importante, acciones que impulsan el valor comercial. Al tratar de hacerlo, las empresas se encuentran saturadas de datos. Tanto es así que ha surgido la demanda de grandes necesidades de computo y almacenamiento, muy bien administrada por los proveedores de nube pública. Pero el costo del transporte y la velocidad de procesamiento también han aumentado, lo cual es un desafío para muchos casos de uso como los servicios de misión crítica.

El tema del trasporte es un detalle a considerar. En gran medida el avance de este modelo vendrá impulsado por despliegue de la red #5G, y todas las ventajas operacionales que esto tendrá aparejado como por ejemplo la baja latencia. #Cisco, #Dell, #Intel, #Microsoft entre otros armaron un consorcio llamado #OpenFog, para trabajar en el concepto de #FOG computing, una capa de red por debajo de las nubes que permita incrementar la conectividad del mundo.

Para simplificarla un poco: FOG tiene que ver con el transporte, EDGE tiene que ver con el procesamiento.

Para finalizar el post, me quedo con esta frase de Tony Antoun, SVP de GE Digital:

“Para habilitar la transformación digital, debe desarrollar el lado EDGE de la informática y conectarlo con la nube; es un viaje desde EDGE a la nube y viceversa”.

Edge Computing

[popup_anything id=”2076″]