Bluetab

an IBM Company

Bluetab

$ docker run 2021

by

$ docker run 2021

David Quintanar Pérez

Consultor BI

Cuando estaba en la universidad, en mi primera clase de Base de Datos Distribuida, conocí Docker. Al principio fue algo extraño, algo que no me pasaba por la mente que pudiera existir, el amor al desarrollo a primera vista.

Problemas que surgen al desarrollar

Cuando pensaba en aprender, experimentar o construir software, lo hacía sobre mi máquina. En la cual debía instalar todo lo que necesitaba para empezar a desarrollar y me tenía que pelear con las versiones, dependencias, entre otras que toman tiempo.

Luego me enfrenté al reto de compartir eso que había creado con amigos, algún equipo o profesor(a). Sin mencionar que debían instalar todo también y con las mismas especificaciones.

La mejor opción era que desde un inicio lo hicieras en una máquina virtual y pudieras compartirla con todo configurado. Para finalmente enfrentarse al hecho del tamaño que ocupaba. Espero que para este momento no tuviera que simular un cluster.

En la batalla final te encuentras tú, la aplicación y la(s) máquina(s) virtual(es), contra los recursos del computador donde se ejecuta al final. Y aun superando los problemas que ya tuvimos, nos desafiamos de nuevo a las dependencias, al S.O. y recursos del hardware.

Docker como solución

Ese día en la clase, descubrí la herramienta que permite Construir, Distribuir y Ejecutar tu código en donde sea, de una manera fácil y de código abierto.

Esto quiere decir que con Docker, al momento de construir, puedes especificar el S.O. donde ejecutará, las dependencias y versiones de las aplicaciones que ocupará. Asegurando que siempre ejecutará en el ambiente que requiere.

Qué al momento de distribuir lo que construiste, con quien lo necesite, podrá hacerlo rápido, simple y sin preocuparse de pre-instalar, porque ya todo estará definido desde el momento en que empezaste a construir.

Cuando especificaste el ambiente que requieres, lo puedes replicar en desarrollo, producción, o en la computadora que quieras sin esfuerzo extra. Garantizando que mientras tengas Docker, ejecutará de la manera correcta.

«Docker fue creado en el 2013, pero si aún no lo conoces, el 2021 será el año en que empieces a utilizarlo. Hoy en día StackOverflow lo tiene en segundo lugar entre las plataformas que los desarrolladores más aman y en primer lugar como la que más quieren.»

¿Qué es Docker? y ¿Cómo funciona?

Contenedores

Analicemos un poco más a fondo de qué es Docker y cómo funciona. Si ya has tenido un encuentro de primer tipo con esta herramienta, habrás leído o escuchado sobre los contenedores.

Comenzando con el hecho de que los contenedores no son algo único de Docker. Existiendo los contenedores de Linux, que permiten empaquetar y aislar las aplicaciones para poder ejecutarse en diferentes entornos. Docker fue desarrollado a partir de LXN, pero se ha desviado con el tiempo.

Imágenes

Y Docker lo lleva al siguiente nivel, facilitando la creación y diseño de contenedores, con ayuda de imágenes.

Las imágenes se pueden ver como plantillas que contienen un conjunto de instrucciones en orden, que sirven para crear un contenedor y como lo debe hacer.

Docker Hub

Hoy en día Docker Hub es la biblioteca y comunidad más grande del mundo para imágenes de contenedores, en ella podrás encontrar imágenes, obtenerlas, compartir las que tu crees y administrarlas. Solo necesitas crear una cuenta, no dudes en ir a explorar al terminar de leer.

Ejemplo

Ahora imagina que estás desarrollando una aplicación web, necesitas un servicio de HTTP Apache en su versión 2.5 y un servicio de MongoDB en su versión más actual.

Podrías levantar un contenedor por cada servicio o aplicación con ayuda de imágenes predefinidas que obtuviste de Docker Hub y se pueden comunicar entre ellos con ayuda de las redes de Docker.

Utilizar MongoDB, pero que la información de su base de datos se almacene desde un servicio en la nube del proveedor que prefieras. Esto se podrá replicar en el ambiente de desarrollo y de producción de la misma manera, fácil y rápido.

Contenedores vs. Máquinas Virtuales

Una de las diferencias es que los contenedores virtualizan el sistema operativo en lugar del hardware.

Si analizamos otros aspectos, así como múltiples máquinas virtuales se pueden ejecutar en una sola, los contenedores pueden hacer lo mismo, pero los contenedores tardan menos en arrancar.

Y mientras cada máquina virtual incluye una copia completa de un sistema operativo, aplicaciones, etc. Los contenedores pueden compartir el mismo Kernel del S.O. lo cual los puede hacer más livianos. Las imágenes de los contenedores suelen tener un tamaño de decenas de MB y las máquinas virtuales pueden llegar a ocupar decenas de GB.

Existen más aspectos que te invito a buscar porque esto no quiere decir que dejemos de usar máquinas virtuales o que Docker sea mejor, solo que tenemos otra opción.

Se ha vuelto más complejo y flexible poder tener contenedores ejecutándose dentro de máquinas virtuales.

Descargar e instalar Docker

Puedes descargar e instalar Docker en múltiples plataformas (MAC, Windows y Linux) y se puede consultar el manual desde el sitio web oficial.

También existen diferentes proveedores de servicios en la nube que te permiten utilizarlo.

Play with Docker

También tienes la alternativa de probar Docker sin una instalación con Play with Docker. Como su nombre lo dice, podrás jugar con Docker, descargando imágenes o repositorios para correr contenedores en instancias de Play with Docker. Todo al alcance de tu mano con una cuenta de Docker Hub.

2021

Ahora conoces más sobre los problemas que existen al desarrollar, que es Docker y que funciona como solución, un poco sobre su sistema de contenedores e imágenes que puedes crear u obtener de Docker Hub. Sabes algunas diferencias entre las Máquinas Virtuales y Docker. Que docker es multiplataforma y que puedes experimentar con él sin instalarlo en tu computadora con Play with Docker.

Hoy en día cada vez más ofertas de trabajo solicitan Docker, incluso como un valor agregado a los requisitos necesarios para cubrir un puesto. Recuerda que, si estás en el mundo del desarrollo de software, si quieres construir, distribuir y ejecutar código donde sea, de una forma fácil, solucionar tus problemas, experimentar en nuevas tecnologías, aprender y comprender la idea del título en este artículo… Tú, debes aprender Docker.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

5 errores comunes en Redshift

by

5 errores comunes en Redshift

Alvaro Santos

Senior Cloud Solution Architect​

Amazon Redshift se puede considerar como unos de los data warehouse más importantes de la actualidad y que ofrece AWS en su nube. Trabajando en Bluetab, hemos tenido el placer de usarlo en muchas ocasiones con nuestros momentos buenos / malos al igual que este año 2020. Por ello, hemos creado una lista con los errores más comunes que debéis evitar y que esperemos os sirvan de gran ayuda.

En Bluetab llevamos desde hace más de 10 años trabajando alrededor del dato. En muchos de los cuales, hemos ayudado en la evolución tecnológica de muchas empresas migrando sus entornos tradicionales analíticos y BI de Data Warehouse a entornos de Big Data.

Además desde la Práctica Cloud hemos participado en migraciones a la nube y nuevos desarrollos de proyectos de Big Data la nube de Amazon Web Services y Google Cloud. Toda esta experiencia nos ha permitido crear un grupo de personas muy cualificadas que piensan/trabajan por/para la nube.

Para ayudaros con vuestros trabajos en la nube, os queremos presentar los errores más comunes que hemos encontrado a la hora de trabajar con Redhisft, la herramienta de DW más importante que ofrece AWS.

Aquí tenéis la lista de ellos:

  1. Trabajar como si fuera un PostgreSQL.
  2. Cargar datos de aquella manera.
  3. Dimensionar mal el cluster.
  4. No hacer uso de workload management (WLM).
  5. Desentenderse del mantenimiento

Qué es Redshift

Amazon Redshift es un base de datos analítica (OLAP) en la nube muy rápida y totalmente administrada por AWS. Con ella se simplifica y mejora el análisis de datos utilizando SQL estándar compatible con la mayoría de las herramientas de BI existentes.

Las características más importantes de Amazon Redshift son:

  • Almacenamiento de datos en columnas: en lugar de almacenar datos como una serie de filas, Amazon Redshift organiza los datos por columna. Dado que solo se procesan las columnas involucradas en las consultas y los datos en columnas se almacenan secuencialmente en los medios de almacenamiento, los sistemas basados ​​en columnas requieren muchas menos I/O, lo que mejora enormemente el rendimiento de las consultas.
  • Compresión avanzada: las bases de datos columnares se pueden comprimir mucho más que las basados ​​en filas porque los datos similares se almacenan secuencialmente en el disco.
  • Procesamiento masivo paralelo (MPP): Amazon Redshift distribuye automáticamente la carga de datos y consultas en todos los nodos.
  • Redshift Spectrum: Redshift Spectrum le permite ejecutar consultas en exabytes de datos almacenados en Amazon S3.
  • Vistas materializadas: las consultas posteriores que hacen referencia a las vistas materializadas utilizan los resultados pre.calculados para ejecutarse mucho más rápido. Las vistas materializadas se pueden crear en base a una o más tablas de origen utilizando filtros, proyecciones, combinaciones internas, agregaciones, agrupaciones, funciones y otras construcciones SQL.
  • Escalabilidad: Redshift tiene la capacidad de escalar su procesamiento y almacenamiento aumentado el tamaño de cluster a cientos de nodos.

Amazon Redshift no es igual que otros sistemas SQL de base de datos. Para aprovechar adecuadamente todos sus beneficios es necesario que se sigan una buenas practicas, de esa manera el cluster funcionará de manera óptima.

1. Trabajar como si fuera un PostgreSQL

Un error muy común que cometemos al comenzar a usar Redshift, es suponer que Redshift es simplemente un PostgreSQL vitaminado y que partiendo de un schema compatible con él puedes empezar a trabajar con Redshift. Sin embargo, no podrías estar más equivocado.

Aunque es cierto que Redshift se basó en una versión antigua de PostgreSQL 8.0.2, su arquitectura ha cambiado radicalmente y ha sido optimizada durante años para mejorar el redimiendo para su estrictamente analítico. Por ellos es necesario:
  • Diseñar las tablas de manera adecuada.
  • Lanzar consultas optimizadas para entornos MPP.

Diseñar las tablas de manera adecuada

Cuando se diseña la base de datos ten en cuenta que algunas decisiones clave sobre el diseño de las tablas influyen considerablemente en el rendimiento general de la consulta. Unas buenas practicas son:
  • Seleccionar el tipo de distribución de datos óptima:
    • Para las tablas de hechos (facts) elige el tipo DISTKEY. De esta manera los datos se distribuirán en los diferentes nodos agrupados por los valores de la clave elegida. Esto te permitirá realizar consultas de tipo JOIN sobre esa columna de manera muy eficiente.
    • Para las tablas de dimensiones (dimensions) con un pocos de millones de entradas elige el tipo ALL. Aquellas tablas que son comúnmente usadas en joins de tipo diccionario es recomendable que se copien a todos los nodos. De esta manera la sentencia JOIN realizada con tablas de hechos mucho más grandes se ejecutará mucho más rápido.
    • Cuando no tengas claro como vas a realizar la consulta sobre una tabla muy grande o simplemente no tenga ninguna relación con el resto, elige el tipo EVEN. De esta forma los datos se distribuirán de manera aleatoria.
  • Usa la compresión automática permitiendo a Redshift que seleccione el tipo más optimo para cada columna. Esto lo consigue realizando un escaneo sobre un número limitado de elementos.

Usar consultas optimizadas para entornos MPP

Puesto que Redshift es un entorno MPP distribuido, es necesario maximizar el rendimiento de las consultas siguiendo unas recomendaciones básicas. Unas buenas practicas son:
  • Las tablas tiene que diseñarse pensando en las consultas que se van a realizar. Por lo tanto, si una consulta no encaja es necesario que revises el diseño de las tablas que participan.
  • Evite usar SELECT *. e incluye solo las columnas que necesites.
  • No uses cross-joins a no ser que sea necesario.
  • Siempre que puedas, usa la sentencia WHERE para restringir la cantidad de datos a leer.
  • Use claves de ordenación en las cláusulas GROUP BY y SORT BY para que el planificador de consultas pueda usar una agregación más eficiente.

2. Cargar datos de aquella manera

Cargar conjuntos de datos muy grandes puede tomar mucho tiempo y consumir gran cantidad de recursos del cluster. Además si esta carga se realiza de manera inadecuada también puede afectar el rendimiento de las consultas.

Por ello, es recomendable seguir estas pautas:

  • Usa siempre el comando COPY para cargar los datos en paralelo desde Amazon S3, Amazon EMR, Amazon DynamoDB o desde distintos orígenes de datos en hosts remotos.

 copy customer from 's3://mybucket/mydata' iam_role 'arn:aws:iam::12345678901:role/MyRedshiftRole';

  • Si es posible, lanza un solo comando en vez de varios. Puedes usar un fichero manifest o patrones para cargar varios ficheros de una sola vez.

  • Divide los archivos de datos de carga de tal modo que sean:

    • De igual tamaño, entre 1 MB y 1 GB, después de la compresión.
    • Un múltiplo del número de slices de tu cluster.

  • Para actualizar los datos e insertar datos nuevos de manera eficiente al cargarlos usa una tabla provisional.

  -- Crea una tabla provisional y, luego, complétala con los datos que se fusionarán.
  create temp table stage (like target); 

  insert into stage 
  select * from source 
  where source.filter = 'filter_expression';

  -- Usa una combinación interna con la tabla provisional para eliminar las filas de la tabla destino que se están actualizando.
  begin transaction;

  delete from target 
  using stage 
  where target.primarykey = stage.primarykey; 

  -- Inserta todas las filas de la tabla provisional.
  drop table stage;
  insert into target 
  select * from stage;

  end transaction;

  -- Elimina la tabla provisional.
  drop table stage;

3. Dimensionar mal el cluster

A lo largo de los años hemos visto muchos clientes que tenían graves problemas de rendimiento con Redshift debido a fallos de diseño de sus BBDD. Muchos de ellos habían intentado resolverlos añadiendo más recursos al cluster en vez de intentar solucionar el problema de raíz.

Por ellos te propongo que sigas el siguiente flujo para dimensionar tu cluster:

  • Recolecta información sobre el tipo de consultas a realizar, tamaño de los datos, concurrencia esperada, etc.

  • Diseña tus tablas en base a las consultas que se vayan a realizar.

  • Dependiendo del tipo de consultas (sencillas, largas, complejas…), selecciona el tipo de instancia de Redshift (DC2, DS2 o RA3).

  • Teniendo en cuenta el tamaño del dataset, calcula el número nodos de tu cluster.

# of  Redshift nodes = (uncompressed data size) * 1.25 / (storage capacity of selected Redshift node type)

« Para el cálculo del tamaño de almacenamiento, se recomienda tener además un margen mayor para realizar tareas de mantenimiento. »

  • Realizar pruebas de carga para comprobar el rendimiento.

  • En el caso de no funcionar adecuadamente, optimiza las queries modificando el diseño de las tablas incluso si fuera necesario.

  • Finalmente, si no fuera suficiente, itera hasta encontrar el dimensionamiento adecuado de nodos y tamaños.

4. No hacer uso de workload management (WLM)

Es bastante probable que vuestro caso de uso necesite que existan varias sesiones o usuarios que estén ejecutando consultas al mismo tiempo. En estos casos, algunas consultas pueden consumir recursos del clúster durante periodos de tiempo prolongados y afectar al rendimiento de las otras consultas. En esta situación, es posible que las consultas sencillas tendrán que esperar hasta que se complete las consultas más largas.

Mediante el uso de WLM, vamos a poder administrar la prioridad y capacidad de los diferentes tipos de ejecuciones creando diferente colas de ejecución.

Es posible configurar la WLM de Amazon Redshift para su ejecución de dos maneras diferentes:

  • Automatic WLM: la manera más recomendada es habilitar Amazon Redshift para que administre cómo se dividen los recursos para ejecutar consultas simultáneas con WLM automático. El usuario gestiona la prioridad de las colas y Amazon Redshift determina cuántas consultas se ejecutan simultáneamente y cuánta memoria se asigna a cada consulta enviada.
  • Manual WLM: alternativamente, se puede configurar de manera manual el uso de recursos de diferente colas. En tiempo de ejecución, se pueden enviar consultas a diferentes colas con diferentes parámetros de concurrencia y memoria gestionados por el usuario.


Cómo funciona WLM

Cuando un usuario ejecuta una consulta, WLM asigna la consulta a la primera cola coincidente, en función de las reglas de asignación de cola de WLM.

  • Si un usuario inició sesión como superusuario y ejecuta una consulta en el grupo de consultas con la etiqueta super usuario, la consulta se asigna a la cola superusuario.
  • Si un usuario pertenece a un grupo de usuarios de la lista o ejecuta una consulta dentro del grupo de consultas de la lista, la consulta se asigna a la primera cola coincidente.
  • Si una consulta no cumple con ningún criterio, la consulta se asigna a la cola predeterminada, que es la última cola definida en la configuración de WLM.

5. Desentenderse del mantenimiento

El mantenimiento de la base de datos es un término que usamos para describir un conjunto de tareas que se ejecutan con la intención de mejorar la base de datos. Existen rutinas destinadas a ayudar al rendimiento, liberar espacio en disco, verificar errores de datos, verificar fallos de hardware, actualizar estadísticas internas y muchas otras cosas oscuras (pero importantes).

En el caso de Redshift, se tiene la falsa sensación de que al ser un servicio totalmente administrado por Amazon no es necesario realizar ninguna. De esta manera creas el cluster y te olvidas de él. Aunque es cierto que AWS te facilita muchas tareas de administración (crear, parar, arrancar, destruir o realizar backups), esto no podría ser más erróneo.

Las tareas de mantenimiento más importantes que debes de llevar a cabo en Redshift son:

  • Motorización del sistema: es necesario que se monitorize el cluster 24/7 y realices revisiones periódicas para comprobar que el sistema funciona correctamente (sin consultas erróneas o bloqueos, espacio libre, tiempos de respuesta adecuados, etc). Además es necesario crear alarmas para poder anticiparse ante cualquier futura caída del servicio.
  • Compactación de las BBDD: Amazon Redshift no realiza todas las tareas de compactación en todas las situaciones automáticamente y otras veces vas a necesitar ejecutarlas de manera manual. Este proceso es denominado VACUUM y es necesario ejecutarlo manualmente para poder hacer uso de SORT KEYS de tipo INTERLEAVED. Este es un proceso bastante largo y costoso que va a tener que hacerlo a poder ser, en las ventanas de mantenimiento.
  • Integridad de los datos: como en toda carga de datos es necesario revisar que los procesos de ETL han funcionado adecuadamente. Redshift dispone de tablas de sistema como STV_LOAD_STATE en las que es posible encontrar información acerca del estado actual de las instrucciones COPY en curso. Debes de revisarlas a menudo para comprobar que no hay errores en la integridad de los datos.
  • Detección de consultas pesadas: Redshift monitoriza continuamente todas aquellas consultas que están tardando más de lo previsto y que podrían estar afectando negativamente el rendimiento del servicio. Para que puedas analizar e investigar esas consultas es posible encontrarlas en tablas de sistema como STL_ALERT_EVENT_LOG o a través de la misma consola web de AWS.
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Álvaro Santos
Senior Cloud Solution Architect​

Mi nombre es Álvaro Santos y ejerzo como Solution Architect desde hace más de 5 años. Estoy certificado en AWS, GCP, Apache Spark y alguna que otras más. Entré a formar parte en Bluetab en octubre de 2018 y desde entonces estoy involucrado en proyectos cloud de Banca y Energía y además participo como Cloud Master Partitioner. Soy un apasionado de las nuevas patrones distribuidos, Big Data, Open-source software y cualquier otra cosa de mundo IT que mole.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Hashicorp Boundary

by

Hashicorp Series Boundary

Javier Pérez

DevOps Engineer

Javier Rodriguez

Cloud DevOps

Jorge de Diego

Cloud DevOps Engineer

Después de la última HashiConf Digital, desde la Práctica Cloud os queremos enseñar una de las principales novedades que fueron presentadas: Boundary. En este post vamos a comentar qué es esta nueva herramienta, por qué es interesante, qué nos ha parecido y cómo lo hemos probado.

¿Qué es Hashicorp Boundary?

Hashicorp Boundary es, como ellos mismos declaran, una herramienta que permite acceder a cualquier sistema utilizando la identidad como pieza fundamental. ¿Esto qué significa? Tradicionalmente, cuando un usuario adquiere el permiso de acceder a un servicio remoto, también obtiene el permiso explícito a la red donde se encuentra ubicado. Sin embargo, Boundary nos proporcionará un sistema basado en el mínimo privilegio posible cuando los usuarios necesitan acceder a aplicaciones o máquinas. Por ejemplo, es una forma de acceder mediante SSH a un único servidor utilizando como método de autenticación unas claves efímeras.

Esto quiere decir que Boundary limita a qué recursos te puedes conectar y además gestiona los diferentes permisos y accesos a los recursos con una autenticación.

Es especialmente interesante porque en el futuro va a estar marcado por la fuerte integración que tendrá con otras herramientas de Hashicorp, especialmente con Vault para la gestión de credenciales, así como con sus funciones de auditoria.

Por si tenéis curiosidad, Hashicorp ha liberado el código fuente de Boundary el cual tenéis disponible en Github y la documentación oficial la podréis leer en su pagina web: boundaryproject.

¿Cómo hemos puesto a prueba Boundary?

Partiendo de un proyecto de Hashicorp de ejemplo, se ha desarrollado una pequeña prueba de concepto que despliega Boundary en un escenario hybrid-cloud en AWS y GCP. Aunque la arquitectura de referencia no decía nada con respecto a este diseño, nosotros hemos querido darle una vuelta y montar un pequeño escenario multi-cloud para ver cómo se comporta este nuevo producto.

La arquitectura final a grandes rasgos es:

Una vez desplegada la infraestructura y configurada la aplicación hemos probado a conectarnos a las instancias mediante SSH. Todo el código fuente se basa en terraform 0.13 y lo podréis encontrar en Bluetab-boundary-hybrid-architecture, en donde también encontraréis un README detallado que especifica las acciones que tenéis que seguir para reproducir el entorno, en particular:

  1. Autenticación con vuestro usuario (previamente configurado) en Boundary. Para ello apuntamos al endpoint correspondiente a los controladores de Boundary y ejecutamos el comando boundary authenticate.

  2. Ejecutar el comando boundary connect ssh con los argumentos necesarios para apuntar a nuestro target (El target representa una o más máquinas o endpoints).

En este escenario particualr, el target se compone de dos máquinas diferentes: una en AWS y otra en GCP. Si a Boundary no se le indica a qué máquina en concreto se quiere acceder de ese target, Boundary proporcionará acceso de forma aleatoria a una de ellas. De manera automática una vez seleccionada la máquina a la que se quiere acceder, Boundary enrutará la petición hacia el worker adecuado, que es el que tiene acceso a dicha máquina.

¿Qué nos ha gustado?

  • La facilidad de configuración. Boundary sabe perfectamente a qué worker tiene que dirigir la petición teniendo en cuenta a qué servicio o máquina se está solicitando el acceso. Como todo el despliegue (tanto infraestructura como aplicación) se ha hecho desde terraform, la salida de un despliegue sirve como entrada del otro y está todo perfectamente integrado.

  • Ofrece tanto interfaz gráfica como acceso CLI. Aunque aún está en una fase muy temprana del desarrollo, el mismo binario de Boundary ofrece (cuando es configurado como controller) una interfaz gráfica muy limpia, con el mismo estilo que las diferents herramientas de Hashicorp. Sin embargo, no todas las funcionalidades se pueden realizar actualmente desde la interfaz, por lo que es necesario utilizar la CLI.

¿Qué hemos echado en falta?

  • La integración con Vault y los indentity providers (IdPs) todavía esta en el roadmap y hasta siguientes versiones no es seguro que se incluya.

  • La gestión actual del JWT token del cliente de Boundary hacia el control-plane que implica instalar una herramienta para la gestión de secretos.

¿Qué nos falta por probar?

Teniendo en cuenta el nivel de avance del desarrollo del producto actual, nos faltaría por entender y probar para:

  • Gestión de accesos modificando políticas a diferentes usuarios.

  • Realizar una investigación más profunda en los componentes que sirven para gestionar los recursos (scopes, organizations, host sets, etc.)

¿Por qué creemos que este producto tiene potencial?

Una vez que el producto vaya cumpliendo fases en el roadmap que Hashicorp ha declarado, simplificará muchísimo la gestión de accesos a máquinas a través de bastiones en las organizaciones. Se podrá gestionar el acceso a una máquina simplemente añadiendo o modificando los permisos que un usuario posee, sin tener que distribuir claves ssh, realizar operaciones manuales en las máquinas, etc.

En resumen, este producto nos brinda una nueva forma de gestionar accesos a diferentes recursos. No solamente mediante SSH, sino que será una forma de gestionar accesos mediante roles a máquinas, bases de datos, portales, etc. minimizando el posible vector de ataque cuando se dan permisos a contratistas. Además se presenta como una herramienta gratuita y opensource, que se integrará muy eficazmente si se tiene el ecosistema de Hashicorp desplegado, pero también servirá en caso contrario sin necesidad del resto de herramientas de esta compañía.

Y una cosa más...

Nos surgió un problema causado por la forma en la que se persistía la información sobre las direcciones de red de los controllers y los workers para su posterior comunicación. Después de hacer funcionar la prueba de concepto mediante un workaround basado en iptables decidimos abrir una https://github.com/hashicorp/boundary/issues/758 en Github. En literalmente un día, nos resolvieron la incidencia actualizando su código. Nos descargamos la nueva versión del código, lo probamos y funcionó a la perfección. Punto a favor para Hashicorp por la rapidez de respuesta y la eficiencia que demostraron. Además, recientemente ha sido liberada la nueva release de Boundary, la cual incluye entre muchas otras cosas, el fix a esta issue Boundary v0.1.2.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Calidad del dato de la información de seguros

by

Calidad del dato de la información de seguros

Nuestro cliente es una de las mayores entidades financieras con presencia principalmente en Europa y América; entre las tres mayores aseguradoras del mercado en México y líder también en las geografías que opera. En los últimos años ha emprendido una transformación digital logrando crear una plataforma tecnológica de última generación.

En Bluetab México somos uno de los principales partners del grupo y hemos colaborado con ellos,  realizando un profundo análisis, para poder identificar los problemas de calidad de datos en los activos informacionales de su rama de Seguros; realizando reingeniería de raíz de algunos procesos para asegurar la calidad de la información, así como también en el desarrollo y automatización de procesos para estructurar la información del día a día, de forma que cumpla con los estándares marcados en la plataforma de Big Data de nuestro cliente.

El alcance de este proyecto es brindar a nuestro cliente mecanismos que le permitan aprovechar una de sus ventajas competitivas utilizando la información que posee sobre sus clientes, que es una de las carteras más grandes del país y transformarla en conocimiento para ofrecer a éstos una mejor experiencia a través de una oferta personalizada.

Un beneficio adicional es que cuenta con información fiable, disponible y ordenada que le permite cumplir con la calidad adecuada para sus procesos regulatorios y de toma de decisiones.

CASOS DE ÉXITO

Data-Drive Agriculture; Big Data, Cloud & AI aplicados

by

Data-Drive Agriculture; Big Data, Cloud & AI aplicados

José Carranceja

Director Operaciones América

Hace unas semanas un cliente nos pidió que le contáramos como estaban posicionadas las tres big clouds en el mundo de la agricultura. Realmente no es una pregunta fácil, pero intentaré resumir algunos elementos que, desde mi experiencia, resultan relevantes acerca del estado de aplicación de las últimas tecnologías de datos en el sector. Un sector en el que la pandemia del coronavirus y su impacto en la escasez de trabajadores, han dado lugar a un aumento del interés por la inversión en robótica y la automatización.

En toda la cadena de valor del mercado agroalimentario hay realmente infinidad de soluciones de aplicación de tecnologías de analítica avanzada, empezando por soluciones cercanas al cliente final bajo el paraguas de los CRM y el Social Marketing, pasando por soluciones de automatización de procesos productivos bajo los ERP y la robotización de las operaciones, y por descontado soluciones de toda la cadena de logística en el ámbito del SCM, desde la optimización de rutas a la de activos en almacén. Pero son quizás menos conocidas y más específicas de agricultura, aquellas soluciones cercanas a los procesos iniciales en los cultivos y la producción de la materia prima alimentaria.

Probablemente este mercado se ha mantenido reticente a la implantación de grandes proyectos de transformación digital y por ello marginal para los grandes players, debido a la gran dispersión de los productores y su poca coordinación por iniciativas públicas. Pero aún con eso, marcas de la relevancia de Syngenta, DJI, Slantrange o John Deere representan en este momento ejemplos indudables de aplicación de las últimas tecnologías de analítica y datos en el sector.

En las fases productivas la combinación de sensores, drones, reconocimiento de imagen, termografía y espectrografía, vehículos autónomos y biotecnología han conseguido además de multiplicar las capacidades productivas, una drástica reducción de mano de obra, insumos químicos y uso de agua.

Actualmente además de los avances en sistemas de predicción meteorológica, los sistemas GPS o la fotografía satelital, los drones son una de las áreas de mayor desarrollo. Estas plataformas proporcionan información detallada sobre situación hidrológica, maduración de la cosecha o situación fitosanitaria. Las cámaras que montan actualmente plataformas Drone como DJI, permiten desde levantar geometrías tridimensionales del terreno, a identificar con precisión de centímetros donde aplicar agua o productos fitosanitarios y hasta el momento más adecuado para la cosecha de cada metro cuadrado. Todo ello mediante servicios disponibles en plataformas en la nube, utilizando algoritmos disponibles capaces de identificar número y tamaños de cosecha, o plagas específicas y su localización.

Tecnologías donde el procesamiento masivo de imágenes (gráficas, térmicas o espectrográficas) y la identificación de patrones son un elemento fundamental.

No hay que olvidar la gran evolución que los productos de origen químico o biológico están suponiendo. Syngenta a la cabeza de la producción de fertilizantes, semillas y productos fitosanitarios, promueve anualmente su Crop Challenge in Analytics en el que premia proyectos de analítica en todo el mundo para el desarrollo de sistemas eficientes y sostenibles.

Una característica relevante de este sector son los marketplaces, además de las soluciones cloud integradas que procesan las imágenes, proporcionan los resultados y generan las decisiones que conllevan, estos marketplaces provén también los modelos y algoritmos parametrizables para aplicarlos a tus datos. Slantrange a nivel internacional o Hemav en España son referentes de estas plataformas cloud integradas. Y plataformas como Keras o Caffe permiten no quebrarse la cabeza desarrollando algoritmos. Sencillamente hay que buscar los más adecuados, parametrizarlos para tu set de datos y ponerlos a competir para buscar el más eficiente. En Open AI están surgiendo nuevos modelos cada 18 meses.

Otro elemento fundamental son las plataformas de datos abiertos, desde meteorológicos, satelitales o geológicos a históricos en determinadas geografías. El cruce de estos con los datos propios, permiten desde predecir mejor fenómenos meteorológicos y su impacto en la maduración de la cosecha a predecir el futuro volumen de la misma y su valor en el mercado.

Finalmente, un elemento diferencial son los vehículos autónomos de empresas como John Deere que fabrica tractores que utilizan los mismos modelos de inteligencia artificial usados en coches autónomos tan sofisticados como el Waymo de Alphabet. Modelos de reconocimiento de imagen permiten colocar y medir las actuaciones de forma que llegan a reducirse en la aplicación de herbicidas o fertilizantes entre un 70 a un 90%. Hay que tener en cuenta que en condiciones normales aproximadamente un 50% de los fertilizantes se pierden en el ambiente.

En este contexto la revista 360 Market Updates en su informe de 2020, identifica para el mercado al que nomina como “Global Connected Agriculture”, una expectativa de crecimiento CAGR de 17.08% durante el periodo entre 2020 y 2024. Y los grandes players no son ajenos a esta perspectiva.

Intentando discriminar los principales actores en servicios cloud, según Gartner, en este momento son Google GCP, Amazon AWS y Microsoft Azure los lideres diferenciados tanto en infraestructura como en plataforma de analítica o BI. Pero es deficit identificar la más adecuada a un requerimiento genérico, incluso bajando a un nivel de detalle preliminar.

En nuestro análisis de las tres plataformas en el que hemos evaluado capacidades de extracción, integración y gobierno fundamentales, concluimos que las tres cuentan con servicios capaces de dar cobertura equivalente. Evidentemente las politicas de precio de todas se adaptan a los requerimientos de cada situación en los mismos términos de competitividad.

No obstante, bajando al terreno de las soluciones para el sector agroalimentario son AWS y Azure las que han desarrollado modelos de aproximación específicos. Ambos han desarrollado plataformas de integración para soluciones IoT, han integrando servicios para volcado de información de todo tipo de sensores, dispositivos o máquinas, y habilitando servicios para hacerlo tanto en streaming como en batch.

Tanto AWS como Azure cuentan con partners que apoyan los procesos de extracción de dichas plataformas IoT y aseguran las comunicaciones y la captación de los datos. Pero quizás Microsoft ha ido un paso más allá invirtiendo en partners con soluciones específicas end to end en el segment en el que son diferenciales en el sector. Un ejemplo de ello es Slantrange, que cubre el proceso completo que realizan los drones desde la generación de los planes de vuelo al procesamiento de las imagenes tanto termicas como termográficas y su explotación para la toma de decisions por los agricultores. Y en esa misma línea, Microsoft ha llegado a acuerdos con plataformas de drones líderes del mercado como DJI o AirMap y ha desarrollado una plataforma de simulación de vuelo Drone Flight Simulator 3D. Toda esta estrategia focalizada en el eslabón de origen de la cadena del negocio, le proporciona un paso adicional para la preparación de los datos previa al procesamiento en sus plataformas de inteligencia artificial.

El servicio Azure FarmBeats, permite la creación de un espacio especializado para el agricultor donde están integradas las capacidades de procesamiento de imagen de drones o satelital, así como algoritmos de análisis para la toma de decisions sobre cosechas.

Desde Bluetab vemos como la evolución de servicios de las tres plataformas están en un momento de extraordinaria evolución y las tres han entrado en una feroz carrera por asegurar que están a la altura de los servicios de sus mas cercanos competidores. Hoy en día cualquiera de las llamadas “killer application” como Kubernetes o kafka están disponibles en las tres y permiten unos niveles de integración de servicios, hasta ahora inpensables.  Por ello, en el análisis de la decision de la Plataforma, hay que incluir también otras variables de decisión importantes como son el nivel de implantación de la Plataforma en nuestro mercado local y la disponibilidad de recursos formados, la integración con nuestras plataformas actuales on premise o las políticas comerciales de cada una de ellas.

Podemos decir en términos generales, que actualmente la plataforma AWS lleva la delantera a sus competidores en lo que tiene que ver con posición de mercado, si bien ha tenido una pequeña reducción de su posición en el ultimo año. Y esto hace que en mercados como España o México nuestra percepción es que el número de recursos disponibles es tambien mayor.

Sin embargo, es claro que el nivel de preexistencia de soluciones Microsoft en el mercado corporativo y las facilidades de integración de toda su plataforma office con soluciones específicas como Power BI, hacen que la afinidad de uso para los usuarios posicione a Azure como la solución alternativa más demandada. Actualmente Power BI es una de las tres plataformas de explotación lideres conjuntamente con Tableau y Qlik.

Por otro lado, Google con GCP focaliza su estrategia en sus soluciones específicas de inteligencia artificial y machine learning como son sus soluciones de lenguaje natural o reconocimiento de imagen y sus plataformas tensorflow. Todo ello apoyado por la integración con sus plataformas de servicios bien conocidas como Maps o Adds. Y todo ello hace que su posición como tercer player esté afianzándose.

Finalmente hay que tener en cuenta dos puntos adicionales, el primero es que cada vez más el concepto multicloud es una realidad y herramientas como VM Ware permiten soluciones de gestion integradas para la coexistencia de diferentes soluciones con diferentes clouds. Por ello y este es el segundo punto, hay que evaluar los requerimientos específicos de cada servicio para valorar si alguna de ellas tiene un nivel de desarrollo superior. Así por ejemplo, en lo que tiene que ver con plataformas de gaming, Microsoft con Xbox parecería ser el lider, pero en este momento Lumberyard el motor de videjuegos y Twitch, ambos de AWS o Google Stream están entrando con fuerza. Y como en esto, en todos los segmentos, los tres competidores se reposicionan en pocos meses, por lo que las ventanas de diferenciación son a veces marginales.

Un mercado apasionante donde cada vez más las tres plataformas AWS, GCP y Azure, dificultan el acceso a otras como Alibaba, IBM y otros competidores, y profundizan en su posición generando oligopolios reales… pero este complejo asunto lo abordaremos en otra occasion.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
José Carranceja
Director Operaciones América

Actualmente COO de Bluetab para América, y ha desarrollado su carrera profesional en diferentes puestos de gestión internacional en áreas de ventas y consultoría en empresas como IBM, BT o Bankinter. Además, ha liderado iniciativas de emprendimiento como JC Consulting Ass. de consultoría tecnológica o Gisdron un start up de servicios drone. Es Arquitecto especialista en cálculo de estructuras y se ha formado en escuelas de posgrado como IESE, INSEAD o el TEC de Monterrey.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Bluetab se certifica como AWS Well Architected Partner Program

by

Bluetab se certifica como AWS Well Architected Partner Program

Bluetab

Dentro de nuestro camino de referentes especializados en Data Solutions /bluetab ha obtenido la certificación del AWS Well Architected Partner Program. Esto nos habilita para acompañar a nuestros clientes en el diseño y optimización de cargas de trabajo en base a las prácticas recomendadas de AWS. 
Nuestro ADN de Professional Excellence, nos acredita para establecer buenos hábitos de arquitectura, minimizar riesgos, y responder de manera ágil ante cambios que impacten en diseños, aplicaciones y cargas de trabajo.
Si eres cliente de AWS y necesitas crear soluciones de alta calidad o controlar el estado de tus cargas de trabajo, no lo dudes y contacta con nosotros en inquiries@beta.bluetab.net.

¿Qué hacemos con WAPP?

Establecer medidas técnicas, tácticas y estratégicas a fin de aprovechar las oportunidades de mejora existentes en cada uno de los diferentes ámbitos

Optimización de costes
Identificar acciones recurrentes sustituible o piezas innecesarias que permitan reducir costes.

Seguridad
Establecer los riesgos de datos y sistemas

Eficiencia
Fijar los recursos necesarios para no incurrir en duplicidades, sobrecargas o cualquier otra ineficiencia.

Excelencia
Supervisar y controlar la ejecución para realizar mejoras continuas y mantener los demás pilares adecuadamente.

Fiabilidad
Visualizar los errores que afecten a cliente corrigiendo y recuperando de forma ágil

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

© 2025 Bluetab Solutions Group, SL. All rights reserved.