Bluetab

Targeted Innovation

Bluetab

Big Data e IoT

by

Big Data e IoT

Bluetab Utilities & Energy

Share on twitter
Share on linkedin

MODELO PARA LA ASOCIACIÓN DE LA ALIMENTACIÓN DE CONTADORES EN REDES

Nuestro cliente, una empresa de energía líder del sector en España y con negocio internacional, en su estrategia de gestión dinámica de la demanda de energía, requería la asociación de los contadores distribuidos por la red en las instalaciones de cliente, a los diferentes transformadores en los centros de transformación, y a sus diferentes salidas de baja tensión bien monofásica o trifásica, en el mismo transformador

Trabajando con una de las Universidad más prestigiosas de Madrid, se migró el algoritmo desarrollado. El objetivo de dicho algoritmo es asociar de forma probabilística, dado un contador de un cliente, su salida y fase en el centro de transformación al que está conectado. Dicho de forma alternativa, identificar la fase y salida de baja tensión que alimenta a cada uno de los contadores de los centros de transformación de baja tensión que dispongan de supervisión avanzada. Todo ello mediante una medida de dependencia usada en el campo de la estadística y teoría de la probabilidad, denominada distancia de correlación o covarianza de la distancia.

Este proyecto de productivización se implementó sobre una arquitectura AWS. EL adecuado tratamiento de la gran cantidad de información producida, el entendimiento de la monitorización y supervisión de los transformadores de la red y la detección de los cambios incrementales de tensión, y la medición de consumos en los contadores transferidos por la red PLC fueron críticos para la implementación adecuada.

Registros de suministro x 6meses históricos = +720M

Registros en transformadores x 6meses históricos = +214MM   

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

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

$ docker run 2021

by

$ docker run 2021

David Quintanar Pérez

Consultor BI

Share on twitter
Share on linkedin
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
Share on twitter
Share on linkedin

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​

Share on twitter
Share on linkedin

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
Share on twitter
Share on linkedin
Á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

Share on twitter
Share on linkedin

Javier Pérez

DevOps Engineer

Javier Rodriguez

Cloud DevOps

Jorge de Diego

Cloud DevOps Engineer

After the last HashiConf Digital, the Cloud Practice wants to present you one of the main innovations that were presented: Boundary. In this post we are going to discuss what offers this new tool, why it is interesting, what we have found and how we have tested it.

What is Hashicorp Boundary?

Hashicorp Boundary is, as themselves claim, a tool that allows access any system using identity as a fundamental piece. What does this really mean?
Traditionally, when a user acquires the permission to access a remote service, he or she also gets explicit permission to the network where the service resides. However, Boundary, following the minimum privilege principle, provides us with an identity-based system for users who need access to applications or machines. For example, it is an easy way of access to a server via SSH using ephemeral keys as authentication method.

This means that Boundary limits what resources you can connect to and also manages the different permissions and accesses to resources with an authentication.

It is especially interesting because in the future it will be marked by the strong integration that it will have with other Hashicorp tools, especially Vault for credentials management and audit capabilities.

In case you are curious, Hashicorp has released the source code of Boundary which you have available at Github and the official documentation can be read on their website:
boundaryproject.

How have we tested Boundary?

BBased on an example project from Hashicorp, we have developed a small proof of concept that deploys Boundary in a hybrid-cloud scenario in AWS and GCP. Although the reference architecture does not said nothing about this design, we wanted to complete the picture and
set up a small multi-cloud stage to see how this new product.

The final architecture in broad terms is:

Once the infrastructure has been deployed and the application configured, we have tested connecting to the instances through SSH. All the source code is based on terraform 0.13 and you can find it in Bluetab-boundary-hybrid-architecture, where you will also find a detailed README that specifies the actions you have to follow to reproduce the environment, in particular:

  • Authentication with your user (previously configured) in Boundary. To accomplish this, you have to set the Boundary controllers endpoint and execute the following command: boundary authenticate.
  • Execute: boundary connect ssh with the required parameters to point to the selected target (this target represents one or more instances or endpoints)

In this particular scenario, the target is composed by two different machines:
one in AWS and one in GCP. If Boundary is not told which particular instance you want to access from that target, it will provide access to one of them randomly. Automatically, once you have selected the machine you want to access, Boundary will route the request to the appropriate worker, who has access to that machine.

What did we like?

  • The ease of configuration. Boundary knows exactly which worker has to address the request taking into account which service or machine is being requested.
    As the entire deployment (both infrastructure and application) has been done using terraform, the output of one deployment serves as the input of the other and everything is perfectly integrated.

  • It offers both graphic interface and CLI access. Despite being in a very early stage of development, the same binary includes (when configured as controller) a very clean graphical interface, in the same style as the rest of the Hashicorp tools. However, as not all functionality is currently implemented through the interface it is necessary to make configuration using the CLI.

What would we have liked to see?

  • Integration with Vault and indentity providers (IdPs) is still in the roadmap and until next versions it is not sure that it will be included.

  • The current management of the JWT token from the Boundary client to the control plane which involves installing a secret management tool.

What do we still need to test?

Considering the level of progress of the current product development, we would be missing for understanding and trying to:

  • Access management by modifying policies for different users.

  • Perform a deepest research on the components that manage resources (scopes, organizations, host sets, etc.)

Why do we think this product has great future?

Once the product has completed several phases in the roadmap that Hashicorp has established, it will greatly simplify resources access management through bastions in organizations. Access to instances can be managed simply by adding or modifying the permissions that a user has, without having to distribute ssh keys, perform manual operations on the machines, etc.

In summary, this product gives us a new way to manage access to different resources. Not only through SSH, but it will be a way to manage access through roles to machines, databases, portals, etc. minimizing the possible attack vector when permissions are given to contractors. In addition, it is presented as a free and open source tool, which will not only integrate very effectively if you have the Hashicorp ecosystem deployed, but will also work seamlessly without the rest of Hashicorp’s tools.

One More Thing…

We encountered a problem caused by the way in which the information about the network addresses of controllers and workers for subsequent communication was stored. After running our scenario with a workaround based on iptables we decided to open a issue on Github. In only one day, they solved the problem by updating their code. We downloaded the new version of the code, tested it and it worked perfectly. Point in favour for Hashicorp for the speed of response and the efficiency they demonstrated. In addition, recently it has been published a new release of Boundary, including this fix along with many other features Boundary v0.1.2.

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

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Análisis de vulnerabilidades en contenedores con trivy

by

Análisis de vulnerabilidades en contenedores con trivy

Ángel Maroco

AWS Cloud Architect

Share on twitter
Share on linkedin

Dentro del marco de la seguridad en contenedores, la fase de construcción adquiere vital importancia debido a que debemos seleccionar la imagen base sobre la que ejecutarán las aplicaciones. El no disponer de mecanismos automáticos para el análisis de vulnerabilidades puede desembocar en entornos productivos con aplicaciones inseguras con los riesgos que ello conlleva.

En este artículo cubriremos el análisis de vulnerabilidades a través de la solución Trivy de Aqua Security, pero antes de comenzar, es preciso explicar en qué se basan este tipo de soluciones para identificar vulnerabilidades en las imágenes docker.

Introducción a CVE (Common Vulnerabilities and Exposures)

CVE es una lista de información mantenida por MITRE Corporation cuyo objetivo es centralizar el registro de vulnerabilidades de seguridad conocidas, en la que cada referencia tiene un número de identificación CVE-ID, descripción de la vulnerabilidad, que versiones del software están afectadas, posible solución al fallo (si existe) o como configurar para mitigar la vulnerabilidad y referencias a publicaciones o entradas de foros o blog donde se ha hecho pública la vulnerabilidad o se demuestra su explotación.

El CVE-ID ofrece una nomenclatura estándar para identificar de forma inequívoca una vulnerabilidad. Se clasifican en 5 tipologías, las cuales veremos en la sección Interpretación del análisis. Dichas tipologías son asignadas basándose en diferentes métricas (si tenéis curiosidad, consultad CVSS v3 Calculator)

CVE se ha convertido en el estándar para el registro de vulnerabilidades, por lo que la amplia mayoría de empresas de tecnología y particulares hacen uso de la misma.

Disponemos de múltiples canales para estar informados de todas las novedades referentes a vulnerabilidades: blog oficial, twitter, repositorio cvelist en github o LinkedIn.

Adicionalmente, si queréis información más detallada sobre una vulnerabilidad, podéis consultar la web del NIST, en concreto la NVD (National Vulnerability Database)

Os invitamos a buscar alguna de las siguientes vulnerabilidades críticas, es muy posible que de forma directa o indirecta os haya podido afectar. Os adelantamos que han sido de las más sonadas 🙂

  • CVE-2017-5753
  • CVE-2017-5754

Si detectas una vulnerabilidad, te animamos a registrarla a través del siguiente formulario

Aqua Security – Trivy

Trivy es una herramienta open source enfocada en la detección de vulnerabilidades en paquetes a nivel OS y ficheros de dependencias de distintitos lenguajes:

  • OS packages; (Alpine, Red Hat Universal Base Image, Red Hat Enterprise Linux, CentOS, Oracle Linux, Debian, Ubuntu, Amazon Linux, openSUSE Leap, SUSE Enterprise Linux, Photon OS and Distroless)

  • Application dependencies: (Bundler, Composer, Pipenv, Poetry, npm, yarn and Cargo)

Aqua Security, empresa especializada en el desarrollo de soluciones de seguridad, adquirió trivy en 2019. Junto a un amplio número de colaboradores, son los encargados del desarrollo y mantenimiento de la misma.

Instalación

Trivy dispone de instaladores para la mayor parte de sistemas Linux and macOS. Para nuestras pruebas vamos a utilizar el instalador genérico:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/master/contrib/install.sh | sudo sh -s -- -b /usr/local/bin

Si no queremos persistir el binario en nuestro sistema, disponemos de una imagen docker:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /tmp/trivycache:/root/.cache/ aquasec/trivy python:3.4-alpine

Operaciones básicas

  • Imágenes locales

Trivy dispone de instaladores para la mayor parte de sistemas Linux and macOS. Para nuestras pruebas vamos a utilizar el instalador genérico:

#!/bin/bash
docker build -t cloud-practice/alpine:latest -<<EOF
FROM alpine:latest
RUN echo "hello world"
EOF

trivy image cloud-practice/alpine:latest
  • Imágenes remotas
#!/bin/bash
trivy image python:3.4-alpine
  • Proyectos locales:
    Permite analizar ficheros de dependencias (salidas):
    • Pipfile.lock: Python
    • package-lock_react.json: React
    • Gemfile_rails.lock: Rails
    • Gemfile.lock: Ruby
    • Dockerfile: Docker
    • composer_laravel.lock: PHP Lavarel
    • Cargo.lock: Rust
#!/bin/bash
git clone https://github.com/knqyf263/trivy-ci-test
trivy fs trivy-ci-test
  • Repositorios públicos:
#!/bin/bash
trivy repo https://github.com/knqyf263/trivy-ci-test
  • Cache database
    La base de datos de vulnerabilidades se aloja en github. Para evitar descargar dicha base de datos en cada operación de análisis, podemos utilizar el parámetro --cache-dir <dir>:
#!/bin/bash trivy –cache-dir .cache/trivy image python:3.4-alpine3.9
  • Filtrar por criticidad
#!/bin/bash
trivy image --severity HIGH,CRITICAL ruby:2.4.0
  • Filtrar vulnerabiliades no resueltas
#!/bin/bash
trivy image --ignore-unfixed ruby:2.4.0
  • Especificar código de salida
    Esta opción en muy util en el proceso de integración continua, ya que podemos especificar que nuestro pipeline finalice con error cuando se encuentre vulnerabilidad de tipo critical pero las tipo medium y high finalicen correctamente.
#!/bin/bash
trivy image --exit-code 0 --severity MEDIUM,HIGH ruby:2.4.0
trivy image --exit-code 1 --severity CRITICAL ruby:2.4.0
  • Ignorar vulnerabilidades específicas
    A través del fichero .trivyignore, podemos especificar aquellas CVEs que nos interesa descartar. Puede resultar útil si la imagen contiene una vulnerabilidad que no afecta a nuestro desarrollo.
#!/bin/bash
cat .trivyignore
# Accept the risk
CVE-2018-14618

# No impact in our settings
CVE-2019-1543
  • Exportar salida en formato JSON:
    Esta opción es interesante si quieres automatizar un proceso antes una salida, visualizar los resultados en un front personalizado o persistir la salida con un formato estructurado.
#!/bin/bash
trivy image -f json -o results.json golang:1.12-alpine
cat results.json | jq
  • Exportar salida en formato SARIF:
    Existe un estandar llamado SARIF (Static Analysis Results Interchange Format) que define el formato que deben tener las salidas cualquier herramienta de análisis de vulnerabilidades.
#!/bin/bash
wget https://raw.githubusercontent.com/aquasecurity/trivy/master/contrib/sarif.tpl
trivy image --format template --template "@sarif.tpl" -o report-golang.sarif  golang:1.12-alpine
cat report-golang.sarif

VS Code dispone de la extensión sarif-viewer para la visualización de vulnerabilidades.

Procesos de integración contínua

Trivy dispone de plantillas para las principales soluciones de CI/CD:

#!/bin/bash
$ cat .gitlab-ci.yml
stages:
  - test

trivy:
  stage: test
  image: docker:stable-git
  before_script:
    - docker build -t trivy-ci-test:${CI_COMMIT_REF_NAME} .
    - export VERSION=$(curl --silent "https://api.github.com/repos/aquasecurity/trivy/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')
    - wget https://github.com/aquasecurity/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz
    - tar zxvf trivy_${VERSION}_Linux-64bit.tar.gz
  variables:
    DOCKER_DRIVER: overlay2
  allow_failure: true
  services:
    - docker:stable-dind
  script:
    - ./trivy --exit-code 0 --severity HIGH --no-progress --auto-refresh trivy-ci-test:${CI_COMMIT_REF_NAME}
    - ./trivy --exit-code 1 --severity CRITICAL --no-progress --auto-refresh trivy-ci-test:${CI_COMMIT_REF_NAME}

Interpretación del análisis

#!/bin/bash
trivy image httpd:2.2-alpine
2020-10-24T09:46:43.186+0200    INFO    Need to update DB
2020-10-24T09:46:43.186+0200    INFO    Downloading DB...
18.63 MiB / 18.63 MiB [---------------------------------------------------------] 100.00% 8.78 MiB p/s 3s
2020-10-24T09:47:08.571+0200    INFO    Detecting Alpine vulnerabilities...
2020-10-24T09:47:08.573+0200    WARN    This OS version is no longer supported by the distribution: alpine 3.4.6
2020-10-24T09:47:08.573+0200    WARN    The vulnerability detection may be insufficient because security updates are not provided

httpd:2.2-alpine (alpine 3.4.6)
===============================
Total: 32 (UNKNOWN: 0, LOW: 0, MEDIUM: 15, HIGH: 14, CRITICAL: 3)

+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+
|        LIBRARY        | VULNERABILITY ID | SEVERITY | INSTALLED VERSION |  FIXED VERSION   |             TITLE              |
+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+
| libcrypto1.0          | CVE-2018-0732    | HIGH     | 1.0.2n-r0         | 1.0.2o-r1        | openssl: Malicious server can  |
|                       |                  |          |                   |                  | send large prime to client     |
|                       |                  |          |                   |                  | during DH(E) TLS...            |
+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+
| postgresql-dev        | CVE-2018-1115    | CRITICAL | 9.5.10-r0         | 9.5.13-r0        | postgresql: Too-permissive     |
|                       |                  |          |                   |                  | access control list on         |
|                       |                  |          |                   |                  | function pg_logfile_rotate()   |
+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+
| libssh2-1             | CVE-2019-17498   | LOW      | 1.8.0-2.1         |                  | libssh2: integer overflow in   |
|                       |                  |          |                   |                  | SSH_MSG_DISCONNECT logic in    |
|                       |                  |          |                   |                  | packet.c                       |
+-----------------------+------------------+----------+-------------------+------------------+--------------------------------+
  • Library: librería/paquete donde se ha identificado la vulnerabilidad.

  • Vulnerability ID: Identificador de vulnerabilidad (según estandar CVE).

  • Severity: existe una clasificación con 5 tipologías [fuente] las cuales tienen asignado una puntuación CVSS (Common Vulnerability Scoring System):

    • Critical (puntuación CVSS 9.0-10.0): fallos que podría aprovechar fácilmente un atacante no autenticado y llegar a comprometer el sistema (ejecución de código arbitrario) sin interacción por parte del usuario.

    • High (puntuación CVSS 7.0-8.9): fallos que podrían comprometer fácilmente la confidencialidad, integridad o disponibilidad de los recursos.

    • Medium (puntuación CVSS 4.0-6.9): fallos que, aún siendo más difíciles de aprovechar, pueden seguir comprometiendo la confidencialidad, integridad o disponibilidad de los recursos en determinadas circunstancias.

    • Low (puntuación CVSS 0.1-3.9): resto de problemas que producen un impacto de seguridad. Son los tipos de vulnerabilidades de los que se considera que su aprovechamiento exige unas circunstancias poco probables o que tendría consecuencias mínimas.

    • Unknow (puntuación CVSS 0.0): se otorga a vulnerabilidades que no tienen asignada puntuación.

  • Installed version: versión instalada en el sistema analizado.

  • Fixed version: versión en la que se resuelve el problema. Si no se informa la versión quiere decir que está pendiente de resolución.

  • Title: Descripción corta de la vulnerabilidad. Para más información, consultar NVD.

Ya sabemos interpretar a alto nivel la información que nos muestra el análisis. Ahora bien, ¿qué acciones debería tomar? En la sección Recomendaciones te damos alguna pista.

Recomendaciones

  • En esta sección describimos algunos aspectos más importantes dentro del ámbito de vulnerabilidades en contenedores:

    • Evitar (en la medida de lo posible) hacer uso de imágenes donde se hayan identificado vulnerabilidades critical y high

    • Incluir el análisis de imágenes en procesos de CI
      La seguridad en tu desarrollo no es opcional, automatiza tus pruebas y no dependas de procesos manuales.

    • Utilizar imágenes ligeras, menos exposiciones:
      Las imágenes tipo Alpine / BusyBox están construidas con el menor número de paquetes posible (la imagen base pesa 5MB), lo que se traduce en una reducción de vectores de ataque. Soportan múltiples arquitecturas y se actualizan con bastante frecuencia.
REPOSITORY  TAG     IMAGE ID      CREATED      SIZE
alpine      latest  961769676411  4 weeks ago  5.58MB
ubuntu      latest  2ca708c1c9cc  2 days ago   64.2MB
debian      latest  c2c03a296d23  9 days ago   114MB
centos      latest  67fa590cfc1c  4 weeks ago  202MB
Si por algún motivo de dependencias no podéis customizar una imagen base de alpine, buscad imágenes tipo slim de proveedores de software confiables. Además del componente de seguridad, las personas que compartan red contigo lo agradecerán al no tener que bajar imágenes de 1GB
  • Obtener imágenes de repositorios oficiales: Lo recomendable es utilizar DockerHub y preferentemente imágenes de publishers oficiales. DockerHub y CVEs

  • Mantener actualizadas las imágenes En el siguiente ejemplo vemos un análisis sobre dos versiones diferentes de apache:

    Imagen publicada el 11/2018

httpd:2.2-alpine (alpine 3.4.6)
 Total: 32 (UNKNOWN: 0, LOW: 0, MEDIUM: 15, **HIGH: 14, CRITICAL: 3**)

Imagen publicada el 01/2020

httpd:alpine (alpine 3.12.1)
 Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, **HIGH: 0, CRITICAL: 0**)

Como podéis observar, si un desarrollo finalizó en 2018 y no se realizan tareas de mantenimiento, podría estar exponiendo un apache relativamente vulnerable. No es un problema derivado del uso de contenedores, pero debido a la versatilidad que nos proporciona docker para testar nuevas versiones de productos, ahora no tenemos excusa.

  • Especial atención a vulnerabilidades que afecten a la capa de aplicación:
    Según el estudio realizado por la compañía edgescan, el 19% de las vulnerabilidades detectadas en 2018 corresponden a capa 7 (Modelo OSI), destacando por encima de todos ataques de tipo XSS (Cross-site Scripting).

  • Seleccionar imágenes latest con especial cuidado:
    Aunque este consejo está muy relacionado con el uso de imágenes ligeras, consideramos hacer un inciso sobre las imágenes latest:

Imagen latest Apache (base alpine 3.12)

httpd:alpine (alpine 3.12.1)
 Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

Imagen latest Apache (base debian 10.6)

httpd:latest (debian 10.6)
 Total: 119 (UNKNOWN: 0, LOW: 87, MEDIUM: 10, HIGH: 22, CRITICAL: 0)

En ambos casos estamos utilizando la misma versión de apache (2.4.46), la diferencia está en el número de vulnerabilidades críticas.
¿Quiere decir que la imagen basada en debian 10 convierte en vulnerable la aplicación que ejecuta en ese sistema? Puede que si o puede que no, hay que evaluar si las vulnerabilidades pueden comprometer nuestra aplicación. La recomendación es utilizar la imagen de alpine.

  • Evaluar el uso de imágenes docker distroless
    El concepto distroless es de Google y consiste en imágenes docker basadas en debian9/debian10, sin gestores de paquetes, shells ni utilidades. Las imágenes están enfocadas a lenguajes de programación (Java, Python, Golang, Node.js, dotnet y Rust), contiene exclusivamente lo necesario para ejecutar las aplicaciones. Al no disponer de gestores de paquetes, no puedes instalar tus propias dependencias, lo que se puede traducir en una gran ventaja y en otros casos, un gran obstáculo. Realizad pruebas y si encaja con los requisitos de vuestro proyecto, adelante, siempre es beneficioso disponer de alternativas. El mantenimiento corre a cuenta de Google, así que el aspecto de seguridad estará bien acotado.

Ecosistema de analizadores de vulnerabilidades para contenedores

En nuestro caso hemos utilizado trivy ya que se trata de una herramienta open source, fiable, estable y en continua evolución, pero disponemos de multitud de herramientas para el análisis de contenedores:

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Share on twitter
Share on linkedin
Ángel Maroco
AWS Cloud Architect

Ángel Maroco llevo en el sector IT más de una década, iniciando mi carrera profesional con el desarrollo web, pasando una buena etapa en distintas plataformas informacionales en entornos bancarios y los últimos 5 años dedicado al diseño de soluciones en entornos AWS.

En la actualidad, compagino mi papel de arquitecto junto al de responsable de la Pŕactica Cloud /bluetab, cuya misión es impulsar la cultura Cloud dentro de la compañía.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

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

by

Detección de Fraude Bancario con aprendizaje automático II

José Carranceja

Director Operaciones América

Share on twitter
Share on linkedin
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
Share on twitter
Share on linkedin
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

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