Internet de las Cosas, a nivel industrial

En el año 2015, dentro del marco del evento Sinergias, tuvimos la oportunidad de platicar de qué era y qué tecnologías conforman la Tercera Plataforma. ¿Lo recuerdan? Estas son:

• Cómputo en La Nube
• Big Data y Analíticos
• Mobilidad
• Social Business

Posteriormente en el año 2016 en el marco del mismo evento anual, avanzábamos lo que en aquel entonces era la "novedad" y ahora es el cimiento y la piedra angular de lo que estamos viviendo: La Cuarta Revolución Industrial.

2017 nos recibió con esa hija que tuvieron la Tercera Plataforma y la Cuarta Revolución Industrial. Digna sobrina de la Convergencia Informática y hoy por hoy lo que está marcando la pauta de todo lo que respecta a las Tecnologías de la Información. La Transformación Digital.

La mejor manera de entender la Transformación Digital y sus inmensos alcances, es entender y poner foco en tecnologías y desarrollos relacionados que son las que la pueden hacer realidad.

Existen pues ya identificadas diez y seis tecnologías que apuntalan la Transformación Digital. Doce de ellas ya están impactando nuestras vidas desde hace no mas de un año ni menos de seis meses, mientras que las restantes doce lo harán en un mediano plazo no mayor a ocho años.

Las primeras doce tecnologías con impacto a corto plazo son:

• Cómputo en La Nube (de la Tercera Plataforma)
• Big Data (de la Tercera Plataforma)
• Blockchain (de la Cuarta Revolución Industrial)
• Realidad Virtual (de la Cuarta Revolución Industrial)
• Realidad Aumentada (de la Cuarta Revolución Industrial)
• Internet de las Cosas (de la Cuarta Revolución Industrial)
• Inteligencia Artificial (de la Cuarta Revolución Industrial)
• Vehículos Autónomos (de la Cuarta Revolución Industrial)
• Robots (desde la Tercera Revolución Industrial)
• Fábricas Oscuras  (de la Cuarta Revolución Industrial)
• Impresión 3D (de la Cuarta Revolución Industrial)
• Biología Sintética (de la Cuarta Revolución Industrial)

Las otras cuatro tecnologías con impacto a largo plazo son:

• Auto Ensamble Molecular 
• Cómputo Cuántico
• Cómputo Orgánico
• Interfaces Cibernéticas

En esta entrada, deseamos platicar con un poco de más profundidad acerca de la Internet de las Cosas. ¿Están preparados?

En no pocas entradas anteriores en este Blog Tecnológico, hemos platicado que Internet de las Cosas se define (estricta y teóricamente) como:

-"...un concepto que se refiere a la interconexión digital de objetos cotidianos con internet."- Wikipedia

¿Para qué conectar estos objetos cotidianos utilizando la red de redes? Para que éstos (los objetos) se conviertan es sensores, actuadores y en esos chivatos, chismosos, cotillones que nos pueden hacer la vida más fácil, así como proporcionar valiosísimos datos a las empresas que fabrican electrodomésticos, vehículos, equipos de cómputo, teléfonos inteligentes, etc.

Mas sin embargo Internet de las Cosas no es solamente conectarlo todo y a todos a la Internet, como en una masiva tertulia en la que todos hablamos contra todos, sin llegar a un claro y concreto objetivo.

¿Cómo hacer entonces para de manera ordenada, útil, rentable y trascendente podamos aprovechar a nuestros artilugios cotidianos (y no tanto) conectados a la Web?

Estándares y protocolos para Internet de las Cosas

Comencemos pues con una visión general de los protocolos involucrados en dispositivos y aplicaciones de Internet de las Cosas.

Internet de las Cosas abarca una amplia gama de industrias y se presentan casos que varían desde un solo dispositivo restringido, hasta despliegues masivos multi-plataforma de tecnologías integradas y sistemas en la nube que se conectan en tiempo real.

Interconectar todo esto requiere numerosos protocolos de comunicación ya existentes y emergentes, que permiten que los dispositivos y servidores se comuniquen entre sí de formas nuevas y más interconectadas.

Al mismo tiempo, se están formando docenas de alianzas y coaliciones con la esperanza de unificar el panorama IoT fracturado y orgánico.

A continuación veremos:

• Una lista general de protocolos y estándares populares que ayudan a impulsar dispositivos, aplicaciones y aplicaciones de IoT
• Profundizaremos en capas específicas o protocolos específicos de la industria
• Haremos una lista de las comparaciones cara a cara de los protocolos populares

Protocolos

En lugar de intentar ajustar todos los protocolos IoT sobre los modelos de arquitectura existentes como el modelo OSI, hemos desglosado los protocolos en las siguientes capas para proporcionar un cierto nivel de organización:

• Infraestructura (por ejemplo, 6LowPAN, IPv4/IPv6, RPL)
• Identificación (ej .: EPC, uCode, IPv6, URI)
• Comunicaciones/Transporte (por ejemplo: Wifi, Bluetooth, LPWAN)
• Descubrimiento (por ejemplo: Physical Web, mDNS, DNS-SD)
• Protocolos de datos (por ejemplo: MQTT, CoAP, AMQP, Websocket, Node)
• Administración de dispositivos (por ejemplo: TR-069, OMA-DM)
• Semántica (ej .: JSON-LD, "Web Thing Model")
• Frameworks multicapa (ej: Alljoyn, IoTivity, Weave, Homekit)
• Seguridad (hogar conectado, industria, etc.)

Infraestructura

IPv6: "IPv6, es un protocolo de capa de Internet (evolución de IPv4) para interconexión de conmutación de paquetes, que proporciona transmisión de datagramas de extremo a extremo a través de múltiples redes IP.

6LoWPAN: Acrónimo de "IPv6 Sobre Redes Inalámbricas de Área Personal de Baja Potencia. Es una capa de adaptación para IPv6 sobre enlaces IEEE802.15.4. Este protocolo opera solo en el rango de frecuencias de 2,4 GHz con una tasa de transferencia de 250 kbps.

UDP (User Datagram Protocol - Protocolo de Datagramas de Usuario): Protocolo simple de capa de transporte OSI, para aplicaciones de red cliente/servidor basadas en Protocolo de Internet (IP). UDP es la principal alternativa a TCP y uno de los protocolos de red más antiguos en existencia, introducido en 1980. UDP a menudo se utiliza en aplicaciones especialmente optimizadas para el rendimiento en tiempo real.

QUIC (Quick UDP Internet Connections - Conexiones Rápidas a Internet vía UDP): Admite un conjunto de conexiones multiplexadas entre dos puntos finales a través del Protocolo de Datagramas de Usuario (UDP). diseñado para proporcionar protección de seguridad equivalente a Transport Layer Security (TLS)/Secure Socket Layer (SSL), junto con una latencia reducida de conexión, transporte y estimación de ancho de banda en cada dirección para evitar congestión.

Aeron: UDP confiable y eficiente en modalidad de difusión única, multidifusión UDP y transporte de mensajes Inter-Process Communication (IPC).

uIP: Pila (stack) de código abierto del protocolo TCP/IP, que se puede usar con pequeños microcontroladores de 8 y 16 bits. Originalmente fue desarrollado por Adam Dunkels del grupo "Networked Embedded Systems" en el Instituto Sueco de Ciencias de la Computación, con licencia Berkeley Software Distribution (BSD) y desarrollado por un amplio grupo de desarrolladores.

DTLS (Datagram Transport Layer): Proporciona privacidad de comunicaciones para protocolos de datagramas. El protocolo permite que las aplicaciones cliente/servidor se comuniquen de manera tal, que evite las escuchas, la manipulación o la falsificación de mensajes. El protocolo DTLS se basa en El protocolo Transport Layer Security (TLS) y proporciona garantías de seguridad equivalentes.

ROLL/RPL: Enrutamiento IPv6 para Redes de Baja Potencia y/o Baja Pérdida. Las edes de bajo consumo y bajas pérdidas (LLN por sus siglas en inglés) son una clase de red en la que tanto los enrutadores como su interconexión están restringidos. Los enrutadores LLN generalmente funcionan con restricciones en la potencia de procesamiento, memoria y energía (energía de la batería). Sus interconexiones se caracterizan por altas tasas de pérdida, baja velocidad de datos e inestabilidad.

NanoIP: Nano Internet Protocol, es un concepto que se creó para llevar servicios de red similares a Internet a dispositivos integrados y sensores, sin la sobrecarga de TCP/IP. NanoIP se diseñó para condiciones con gastos generales mínimos, redes inalámbricas y el direccionamiento local.

Red centrada en contenido (CCN): Arquitectura de red de próxima generación, pensada para resolver los desafíos en la escalabilidad, movilidad y seguridad para la distribución de contenido.

CCN enruta directamente y entrega piezas de contenido con nombre en el nivel de paquete de la red, lo que permite el almacenamiento en caché automático y neutral de la aplicación en cualquier lugar de la red. ¿El resultado? Entrega eficiente y efectiva de contenido donde sea y cuando sea necesario. Dado que la arquitectura permite estos efectos de almacenamiento en caché como un efecto secundario automático de la entrega de paquetes, la memoria se puede utilizar sin costosos servicios de caché a nivel de aplicación.

Time Synchronized Mesh Protocol (TSMP): Protocolo de comunicaciones para redes auto-organizadas de dispositivos inalámbricos llamados "motes". Los dispositivos TSMP se mantienen sincronizados entre sí y se comunican en intervalos de tiempo, de forma similar a otros sistemas de Multiplexación por División de Tiempo (TDM por sus siglas en inglés).

Descubrimiento

mDNS (sistema de multidifusión de nombres de domini): Resuelve los nombres de host a direcciones IP dentro de redes pequeñas que no incluyen un servidor de nombres local.

Web Física: la Web física le permite ver una lista de las Universal Resource Locators (URLs) que emiten los objetos en el entorno que lo rodea, con una baliza Bluetooth de Baja Energía (BLE).

HyperCat: un formato de catálogo hipermedia abierto y ligero basado en Java Script Open Notation (JSON) para exponer colecciones de Universal Resource Locators (URIs).

UPnP (Plug and Play universal): Ahora administrado por Open Connectivity Foundation, es un conjunto de protocolos de red que permite a los dispositivos conectados, descubrir la presencia de los demás nodos en la red, estableciendo servicios de red funcionales para compartir datos, comunicaciones y entretenimiento.

Protocolos de datos

MQTT (Message Queue Server Telemetry Transport): Habilita un modelo de mensajería de publicación/suscripción de una manera extremadamente ligera. Es útil para las conexiones con ubicaciones remotas donde se requiere una pequeña huella de código y/o ancho de banda de la red.

MQTT-SN (MQTT para redes de sensores): un protocolo de publicación/suscripción abierto y ligero, diseñado específicamente para aplicaciones Máquina-a-Máquina y móviles:

• Mosquitto: Un Broker v3.1 Open Source MQTT
• IBM MessageSight

CoAP (Protocolo de aplicación restringido): Es un protocolo de capa de aplicación, diseñado para dispositivos de Internet con recursos limitados como los nodos WSN. CoAP está diseñado para traducirse fácilmente a HTTP para una integración simplificada con la web, al mismo tiempo que cumple con los requisitos especializados como el soporte de multidifusión, gastos generales muy bajos y simplicidad.

El Grupo de Entornos RESTful Restringidos (CoRE por sus siglas en inglés) ha propuesto las siguientes características para CoAP:

• Diseño de protocolo RESTful que minimiza la complejidad del mapeo con HTTP.
• Sobrecarga de encabezado baja y la complejidad de análisis.
• URI y soporte de tipo de contenido.
• Soporte para el descubrimiento de recursos proporcionados por Servicios de CoAP. 
• Suscripción simple para un recurso, y notificaciones push resultantes.
• Almacenamiento en caché simple basado en max-age.

SMCP: Una pila de CoAP basada en C, que es adecuada para entornos integrados. Las características incluyen: Soporte draft-ietf-core-coap-13, Entrada/Salida totalmente asíncronas y soporta sockets BSD y UIP.

STOMP: El Protocolo de Mensajería Orientada a Texto Simple, anteriormente conocido como TTMP, es un protocolo  basado en texto diseñado para trabajar con Middleware Orientado a Mensajería (MOM por sus siglas in inglés). Proporciona un formato interoperable que permite a los clientes STOMP hablar con cualquier agente de mensajes que admita el protocolo.

XMPP (Extensible Messaging and Presence Protocol): una tecnología abierta para la comunicación en tiempo real, que impulsa una amplia gama de aplicaciones que incluyen mensajería instantánea, presencia, chat multipartita, llamadas de voz y video, colaboración, middleware ligero, sindicación de contenido y enrutamiento generalizado de datos basados en eXtensible Markup Language o XML.

XMPP-IoT: De la misma manera que XMPP, silenciosamente ha creado una comunicación interoperable de persona a persona. Su objetivo es hacer que las máquinas de comunicación Persona a Persona y Máquina a Máquina sean interoperables.

Mihini/M3DA: El agente de Mihini es un componente de software que actúa como mediador entre un servidor de Máquina a Máquina y las aplicaciones que se ejecutan en una puerta de enlace incrustada. M3DA es un protocolo optimizado para el transporte de datos binarios de máquina a máquina.

Está disponible en el proyecto Mihini tanto para la gestión de dispositivos, facilitando la manipulación y sincronización del modelo de datos de un dispositivo, como para la gestión de activos, permitiendo a las aplicaciones de usuario intercambiar datos / comandos escritos de un lado a otro, con una máquina. Al servidor de la máquina de una manera que optimice el uso del ancho de banda.

AMQP (Protocolo Avanzado de Colas de Mensajería): Protocolo de capa de aplicación estándar, abierto, para middleware orientado a mensajería de datos. Las características definitorias de AMQP son la orientación de los mensajes, la puesta en cola, el enrutamiento (incluyendo punto a punto y publicación y suscripción), así como confiabilidad y seguridad."

DDS (Servicio de Distribución de Datos para Sistemas en Tiempo Real): El primer estándar internacional abierto de middleware, que aborda directamente las comunicaciones bajo el esquema publicación/suscripción para sistemas en tiempo real e integrados".

JMS (Java Message Service): API de Middleware Orientado a Mensajería (MOM) basado en Java,  para enviar mensajes entre dos o más clientes.

LLAP (Protocolo Ligero para Automatización Local): Protocolo que utiliza mensajes corto y simples, que se envía entre objetos inteligentes usando texto normal. No es como TCP/IP, Bluetooth, Zigbee, 6lowpan, WiFi, etc. que alcanza un bajo nivel de "cómo" para mover los datos. Esto significa que LLAP puede correr sobre cualquier medio de comunicación. Las tres fortalezas de LLAP son:

• Se ejecuta en cualquier "cosa" actualmente, 
• Se ejecutará en cualquier "cosa"cualquier cosa en el futuro
• Es fácilmente comprensible para los humanos

LWM2M (Lightweight M2M): Sistema estándar en la Open Mobile Alliance. Incluye DTLS, CoAP, Block, Observe, SenML y Resource Directory, integrándolos en una interfaz de dispositivo-servidor junto con una estructura orientada a Objetos.

SSI (Interfaz de Sensor Simple): Protocolo de comunicaciones simple diseñado para la transferencia de datos entre computadoras o terminales de usuario y sensores inteligentes.

Flujos Reactivos: Estándar para el procesamiento de flujos asíncronos con contrapresión, sin bloqueo en la Máquina Virtual Java (JVM).

Object Name Service (ONS): Mecanismo que aprovecha el Sistema de Nombres de Dominio (DNS) para descubrir información sobre un producto y servicios, basándose en el Código de Producto Electrónico (EPC). Es un componente de la red EPCglobal.

REpresentational State Transfer (REST): Arquitectura que define un conjunto de restricciones que se utilizarán para crear servicios web. Los servicios web que se ajustan a REST, o los servicios web RESTful, proporcionan interoperabilidad entre los sistemas informáticos en Internet.

HTTP/2: El Protocolo de Transferencia de Hipertexto, versión 2, es un protocolo de red utilizado por la World Wide Web que llega con el objetivo de actualizar el protocolo HTTP/1.1, con el que es compatible. HTTP 2.0 no modifica la semántica de aplicación de Http, permitiendo un uso más eficiente de los recursos de red y una menor percepción de la latencia al introducir la compresión del campo del encabezado, permitiendo múltiples intercambios simultáneos en la misma conexión.

SOAP (Protocolo Simple de Acceso a Objetos): Protocolo estándar que define cómo dos objetos en diferentes procesos, pueden comunicarse por medio de intercambio de datos usando XML. Está actualmente bajo el auspicio de la W3C y es uno de los protocolos más utilizados en los servicios Web.

Websocket: Especificación WebSocket desarrollada como parte de la iniciativa HTML5, introduciendo la interfaz JavaScript de WebSocket, que define una conexión de socket único dúplex completo a través de la cual se pueden enviar mensajes entre el cliente y el servidor. Simplifica gran parte de la complejidad en torno a la comunicación web bidireccional y la gestión de la conexión.

En posteriores entregas, hablaremos más acerca de todos los estándares actuales relativos a la Capa de Transporte, Comunicación, Semántica, Frameworks multi capa, Seguridad y estándares específicos.

Por el momento sólo podemos decir que, más allá de pensar que Internet de las Cosas es algo que llegó de manera súbita, improvisada o para intentar cubrir una necesidad general o específica simple, es toda una Tecnología que ya cuenta con todo lo necesario para ser implementada de manera seria, cabal, completa, segura y escalable.

¿Ya tiene Usted pensada su estrategia e Internet de las Cosas?

Trabajando con VMware Cloud en AWS, con REST-API y Python

Introducción

Últimamente hemos estado jugando mucho con la REST-API para VMware Cloud en AWS por una variedad de razones.

Esto nos ha dado una buena visión de muchos casos de uso donde el acceso programático sería preferible al "señalar y hacer clic" de la Interfaz Gráfica de Usuario (GUI por sus siglas en inglés).

Es muy común que aprovechemos el lenguaje Python para llamar a la REST-API, ya que es un lenguaje extremadamente fácil y flexible para empezar.

Es una configuración rápida y normalmente no necesitamos instalar ningún módulo adicional. El módulo "Solicitudes", que es el módulo más común utilizado para interactuar con "endpoints" http(s), se incluye en Python de forma predeterminada.

Como nota al margen, VMware tiene un SDK de Python (y también Java) para interactuar directamente con la API, sin utilizar REST. Podemos consultarlo aquí si deseamos obtener un poco más de Pythonic con sus aventuras en la API.

¡Comencemos!

Introducción: cómo extraer su clave OAuth

Para comenzar, necesitará una cuenta activa de VMware Cloud Services. Con una cuenta activa, desplegamos una clave OAuth que nos permitirá autenticar la API programáticamente.

Esta clave es efectivamente sus credenciales para el medio ambiente, por lo que probablemente debería proteger esto con su vida. Vamos a "exportar" esta clave en Linux para que no tengamos que colocar la clave de forma estática en nuestro código.

Para obtener nuestra clave de OAuth, inicie sesión en la url https://console.cloud.vmware.com y seleccione su nombre en la parte superior derecha, en el menú desplegable, seleccionaremos “OAuth Refresh Token”.

Después de esto, seleccionaremos "Token nuevo" o "Crear un nuevo token" en la página "OAuth Refresh Token".

Recuerde lo que mencionamos antes, este es un código MUY importante. Guárdemoslo de manera segura, guardémoslo con prudencia. ¡Ahora que tenemos este "token", podemos comenzar a bucear en el servicio!

Construyendo Nuestras Llamadas para REST

Estos ejemplos se realizarán en Python 3.6 para Ubuntu en Windows. Sí, usaremos el shell de Linux en Windows. Utilizaremos algunos F String aquí, así que es una buena idea saber lo que hacemos. Son una forma práctica de hacer que nuestro código sea un poco más limpio.

En Linux, podemos usar el comando de exportación para almacenar variables en la memoria y llamarlas dentro de Python, usando el módulo del sistema operativo.

El beneficio de esto es que no se almacenan a largo plazo en un archivo estático en algún lugar donde la gente puede leerlos, y cuando el comando ejecutado en el "shell" termina, ¡ya no está! En este caso, exportaremos oauthkey = 'yourkeydigitshere' y luego lanzaremos nuestro "shell" de Python.

NOTA: Las cadenas F se agregaron en Python 3.6, por lo que si no está ejecutando eso, querrá asignar las variables estáticamente y concatenarlas según sea necesario.

import requests 
import os 

oauth = os.environ['oauthkey']
baseurl = 'https://console.cloud.vmware.com/csp/gateway'
uri = '/am/api/auth/api-tokens/authorize'
headers = {'Content-Type':'application/json'}
payload = {'refresh_token': oauth}
r = requests.post(f'{baseurl}{uri}', headers = headers, params = payload)
print(r.status_code)

Dando un paso atrás para explicar qué está pasando aquí:

• Importamos el módulo de solicitudes para trabajar con nuestros puntos finales API e importamos el módulo os para que interactúe con las variables de entorno. Ambos módulos tienen capacidades extensas fuera de lo que acabo de mencionar, pero esto es para lo que los usamos en esta publicación
• Configuramos el mapa de variables "oauth" a la variable de entorno que establecemos fuera de python utilizando el método "os.environ"
• Establecemos "baseurl" como una variable, específicamente como la URL raíz o "root" con la que vamos a trabajar.
• Configuramos la variable uri como el punto final API al que intentamos llamar, en este caso, estamos llamando al punto final API para la autorización del "token".
• Comenzamos a construir nuestros encabezados y nuestros parámetros. Para nuestra variable de encabezados, establecemos nuestro tipo de contenido que se espera para 'application/json'.
  
  Realmente no NECESITAMOS hacer esto; pero establecer un tipo de contenido es la mejor práctica cuando se trabaja con la API. También establecemos que nuestra carga útil "body" sea un objeto JSON que contenga nuestra clave "OAuth", también conocida como "token de actualización" en la nube de VMware.
• Finalmente, imprimimos el código de estado de la devolución, para saber si entramos. Esperamos un código de estado de respuesta "200". AnythingElse == 'bad'.

¿Cómo sabemos qué URL usar para la autenticación? En la versión más reciente de VMware Cloud en AWS, el equipo lanzó Developer Center, una interfaz de usuario completa construida en torno a las integraciones de la API.

Desde esta vista, podemos navegar al menú "Operaciones de autenticación" y usar esto para ver detalles sobre las diversas llamadas posibles al servicio de autenticación.

Una gran ayuda para Alan Renouf y su equipo por obtener esta función: es una gran ayuda para aquellos de nosotros que estamos tratando de trabajar con VMware Cloud Services desde una perspectiva de la API.

Cuando se ejecuta nuestro "script", con nuestra clave OAuth correctamente aplicada; deberíamos obtener ese código de respuesta 200 sin ningún problema.

Si imprimimos (r.json ()) en este caso, veremos nuestro retorno de token de acceso, junto con el tiempo que tarda en caducar, el tipo de token y algunos valores relacionados con el permiso. Nos hemos autenticado.

¿Cómo podemos mejorar esto? ¿No podemos verificar una falla antes de imprimir? Además, esto funciona bien como un guión, pero ¿y si quisiéramos construir algo un poco extensible? ¿O reutilizar este código en todo nuestro programa? ¿Tiene sentido para nosotros?

Mejorando nuestro inicio de sesión API - Declaraciones y funciones "if"

Podemos realizar comprobaciones proactivas usando una declaración if para verificar y ver "if" la respuesta es lo que queremos que sea.

Como se puede imaginar, para los no adoctrinados, usar una declaración if es muy parecido a decir "si algo es ESTO, haz ALGO, de lo contrario, podemos hacer ESO". En este caso, la actualización es bastante simple.

Podemos agregar el siguiente bloque a nuestro código para hacer que verifique durante el proceso de inicio de sesión, y devolver un error si no puede iniciar sesión correctamente.

if r.status_code != 200:
    print(f'Unsuccessful Login Attempt. Error code {r.status_code}')
else:
    print('Login successful. ') 

Esto es muy fácil de leer, y un ejemplo extremadamente común de una declaración "if" en Python con la REST API. Si el código de estado que se devuelve cuando se ejecuta "r" es algo distinto a 200, imprima el error y díganos el código. De lo contrario, imprima que el inicio de sesión fue exitoso.

Además, la mejor práctica generalmente dice que la creación de funciones es bueno cuando se trata de código. Esto nos permitirá ejecutar un comando simple, como "iniciar sesión", mientras le damos un valor para iniciar sesión correctamente y devolver nuestras credenciales de autenticación.

La mejor parte de esto es que podemos configurar el formato de la respuesta devuelta para que esté en un formato que podamos incluir en OTRAS llamadas a la API.

def login():
    key = os.environ['oauthkey']
    baseurl = 'https://console.cloud.vmware.com/csp/gateway'
    uri = '/am/api/auth/api-tokens/authorize'
    headers = {'Content-Type':'application/json'}
    payload = {'refresh_token': key}
    r = requests.post(f'{baseurl}{uri}', headers = headers, params = payload)
    if r.status_code != 200:
        print(f'Unsuccessful Login Attmept. Error code {r.status_code}')
    else:
        print('Login successful. ')
        auth_json = r.json()['access_token']
        auth_Header = {'Content-Type':'application/json','csp-auth-token':auth_json}
        return auth_Header

El gran problema aquí es ser consciente de nuestro espacio. Python requiere consistencia en esto. Podemos ver que hacemos un simple def login() para comenzar las cosas. Esto declara nuestra función.

A continuación, implementamos el mismo código que nuestro script anterior, con la adición de nuestra verificación de respuesta de estado. Una vez que nuestra verificación se aprueba exitosamente (200 respuestas), imprimimos que el inicio de sesión fue exitoso y construimos nuestro encabezado de autenticación.

Para construir esto, sacamos la clave "access_token" del JSON de la respuesta y la construimos en un nuevo objeto de encabezado llamado "auth_Header", donde establecemos nuestra clave "content-type" y "csp-auth-token". La declaración de devolución al final "devuelve" este encabezado cuando la llamada se realiza correctamente.

Llamando a VMware Cloud vía la AWS REST API

Ahora que tenemos una función de inicio de sesión definida, podemos ser aún más creativos con nuestra llamada a la API. La URL base anterior que usamos es para la API de VMware Cloud Services.

Uno de los componentes principales de esto es el servicio de autenticación. Lo que NO incluye son los Servicios de nube individuales, como la oferta de "VMware Cloud on AWS". Para eso, necesitamos usar una URL DIFERENTE.

Hemos abstraído la mayoría del código de inicio de sesión ahora, lo que acortará drásticamente nuestras próximas llamadas. Probemos uno simple para enumerar todas las organizaciones a las que pertenece la cuenta de usuario de VMwware Cloud Services.

Si miramos el centro de desarrolladores, en el menú "Organizaciones", podemos ver el URI que debemos llamar para extraer los datos de "Org".

Una cosa que no está documentada actualmente en el Centro de desarrolladores, es que la URL base para VMware Cloud en AWS es "https://vmc.vmware.com/vmc/api".

Como puede ver en el centro de desarrolladores, debemos adjuntar "/orgs" a la URL base. Para llamar a esta API, también debemos incluir nuestro encabezado de autenticación en la llamada real. Con nuestra función de inicio de sesión anterior que creamos, esto hace las cosas mucho más simples.

auth_header = login()
orgList = requests.get('https://vmc.vmware.com/vmc/api/orgs', headers = auth_header)
print(orgList.status_code)

¡Éxito! Cuando ejecutamos este código, podemos ver que nuestro código de estado devuelto es 200.

VMware Cloud on AWS API devuelve JSON, por lo que es muy fácil de analizar con Python. Podemos movernos a través del JSON devuelto utilizando un bucle simple para proporcionarnos el nombre y la ID de organización para cada uno de los objetos.

La identificación de la organización es necesaria para llamadas que profundizan en VMware Cloud en AWS, por lo que es importante.

auth_header = login()
orgList = requests.get('https://vmc.vmware.com/vmc/api/orgs', headers = auth_header)
for org in orgList.json():
    print("Org Name: " + org['display_name'])
    print("Org ID: " + org['id'])

Aquí hemos introducido un bucle "for", como mencionamos anteriormente. Básicamente, estamos diciendo "para cada organización en el objeto JSON devuelto por el "orglist", imprima datos desde allí".

Analizamos nuestro JSON, llamando a las claves específicas adjuntas a nuestro bucle "for". Cuando activamos la llamada, usando todo lo que hemos construido hasta ahora, se nos devuelve el siguiente contenido:

"OBTENER" nuestros SDDC's

Para nuestro concepto final, vamos a tomar los datos que hemos llamado anteriormente y devolver los datos de un solo SDDC. Podemos ver en la respuesta que nos devolvieron 2 Organizaciones de nuestra llamada anterior.

Vamos a trabajar con la segunda organización en esa lista. Es un poco engañoso si nunca antes se ha trabajado con un lenguaje de scripting o de codificación, pero "1" en realidad se refiere al segundo elemento de la matriz (siendo 0 el primero). Juguemos con nuestro código un poco más:

auth_header = login()
orgList = requests.get('https://vmc.vmware.com/vmc/api/orgs', headers = auth_header)
orgID = orgList.json()[1]['id']
print(orgID)

Cuando ejecutamos este bloque, podemos confirmar que nuestro "OrgID" se devuelve como se esperaba. Para poder "OBTENER (GET)" y SDDC, debemos volver al centro de desarrolladores para comprender el URI de la API a la que debemos llamar.

Hay un montón de opciones en el menú SDDC, pero finalmente solo queremos el "URI SDDCS" principal. Podemos ver en la llamada que necesitamos alimentar el ID de la organización en el URI de la API. Qué bueno que hayamos establecido cómo hacerlo en la sección anterio. Ya que estamos seguros de que esta llamada a la API va a funcionar, también incluiremos

auth_header = login()
orgList = requests.get('https://vmc.vmware.com/vmc/api/orgs', headers = auth_header)
orgID = orgList.json()[1]['id']
sddcList = requests.get(f'https://vmc.vmware.com/vmc/api/orgs/{orgID}/sddcs', headers = auth_header)
if sddcList.status_code != 200:
    print('API Error')
else:
    for sddc in sddcList.json():
        print("SDDC Name: " + sddc['name'])
        print("SDDC Create Date: " + sddc['created'])
        print("SDDC Provider: " + sddc['provider'])
        print("SDDC Region: " + sddc['resource_config']['region'])

Que largo camino hemos recorrido; y ahora estamos al final. Con estas modificaciones en nuestro script, podemos analizar el resultado del SDDC y obtener algunos datos básicos sobre el clúster SDDC que se ha creado.

Usamos el concepto de "f-string" del que hablamos anteriormente para alimentar en nuestro OrgID a la API "GET" de SDDC. Una vez que recuperamos el valor, analizamos el JSON y extraemos la información relevante que queríamos.

Aquí usamos un bucle "for", pero finalmente solo hay un SDDC en el objeto, por lo que solo se imprime una vez. Sin embargo, si tuviéramos varios SDDC, imprimiría todos:

Éxito. Finalmente hemos llegado a nuestro clúster de vCenter real que vive en AWS y podemos devolver datos desde él.

Conclusión

Aquí se cubren muchos conceptos avanzados, pero podemos ver que es muy fácil llegar a un lugar en el que extraemos datos relevantes de nuestra infraestructura. Hasta ahora nos hemos centrado exclusivamente en las llamadas a la API "GET", pero también hay "PUT", "POST" y "DELETE" que aún no hemos tocado.

¿Imagine crear una función de envío que agregue hosts o los elimine a través de "FaaS"? ¿Se imagina hacerlo en Lambda o vRealize Automation? Imagine desplegar nuevos centros de datos cuando entraste en un nuevo proyecto. Hay muchas opciones con las que podemos jugar.

Cómo Sobrevivir al Apocalipsis Zombie con Microservicios sin Servidor

Reconozcámoslo, administrar servidores puede ser un dolor. La gestión de la capacidad y el escalado son aún peores. Ahora imagina dedicar tu tiempo a Sistemas Operativos durante un apocalipsis zombie: atrinchera la puerta de los comedores de carne con un brazo mientras aplicas un sistema operativo con el otro.

Esto suena como algo sacado de una pesadilla. Por suerte para ti, este no tiene que ser el caso. En AWS, se facilitan más que nunca la creación y el encendido de aplicaciones a escala con potentes servicios administrados, para que podamos centrarnos en su negocio principal, como sobrevivir, mientras manejamos la administración de la infraestructura que nos ayuda a hacerlo.

¡Únete a los "AWS Lambda Signal Corps"!

En el AWS re:Invent en 2015, pusimos a prueba un taller donde los participantes trabajaron en grupos para crear una aplicación de chat sin servidor, para supervivientes del apocalipsis zombie utilizando Amazon S3, Amazon DynamoDB, Amazon API Gateway y AWS Lambda.

Los participantes aprendieron sobre los patrones de diseño de microservicios y las mejores prácticas. Luego extendieron la funcionalidad de la aplicación de chat sin servidor, con varias funcionalidades complementarias como la integración de SMS móvil y la detección de movimiento zombie, utilizando servicios adicionales como Amazon SNS y Amazon Elasticsearch Service.

En esta publicación, mostraremos cómo nuestra aplicación de chat para sobrevivientes incorpora algunos patrones de diseño de microservicios importantes, así cómo también puede potenciar sus aplicaciones de la misma manera con una arquitectura sin servidores.

¿Qué son las arquitecturas sin servidor?

En AWS saben que la administración de la infraestructura puede ser un desafío. También entienden que los clientes prefieren enfocarse en entregar valor a sus negocios. Hay un montón de trabajos pesados ​​indiferenciados para construir y ejecutar aplicaciones, como la instalación de software, la administración de servidores, la coordinación de programas de parches y la ampliación para satisfacer la demanda.

Las arquitecturas sin servidor le permiten construir y ejecutar aplicaciones y servicios sin tener que administrar la infraestructura. Su aplicación aún se ejecuta en los servidores, pero AWS ha hecho toda la administración del servidor para usted. Las arquitecturas sin servidor pueden hacer que sea más fácil construir, administrar y escalar aplicaciones en la nube al eliminar gran parte del trabajo pesado involucrado con la administración del servidor.

Beneficios clave de las arquitecturas sin servidor:

• No hay servidores para administrar: no hay servidores para su aprovisionamiento y administración. AWS ha realizado toda la administración del servidor para usted.
  
• Mayor productividad: ahora puede centrar completamente su atención en la creación de nuevas características y aplicaciones porque se libera de las complejidades de la administración del servidor, lo que le permite iterar más rápido y reducir su tiempo de desarrollo.
  
• Escalado continuo: sus aplicaciones y servicios se escalan automáticamente hacia arriba y hacia abajo según el tamaño de la carga de trabajo.

¿Qué debería esperar aprender en un taller de microservicios Zombie?

El contenido del taller está diseñado para demostrar las mejores prácticas para arquitecturas sin servidor utilizando AWS. En este post discutiremos los siguientes temas:

• ¿Qué servicios son útiles al diseñar una aplicación sin servidor en AWS?
  
• Consideraciones de diseño para mensajería, transformación de datos y lógica empresarial o de nivel de aplicación, al crear microservicios sin servidor.
  
• Las mejores prácticas demostradas en el diseño de la aplicación de chat zombie survivor.
  
• ¡Los siguientes pasos para comenzar a construir sus propios microservicios sin servidor!

Se usaron varios servicios de AWS para diseñar la aplicación "Chat Zombie Survivor". Cada uno de estos servicios es administrado y altamente escalable. Echemos un vistazo rápido a cuáles incorporamos en la arquitectura:

• AWS Lambda le permite ejecutar su código sin aprovisionar o administrar servidores. Simplemente cargue su código (actualmente Node.js, Python o Java) y Lambda se ocupa de todo lo que necesita para ejecutar y escalar su código con alta disponibilidad.
  
  Puede configurar su código para que se active automáticamente desde otros servicios de AWS o llamarlo directamente desde cualquier aplicación web o móvil. Lambda se utiliza para alimentar muchos casos de uso, como aplicaciones de respaldo, tareas administrativas programadas e incluso, grandes cargas de trabajo de datos a través de la integración con otros servicios de AWS como Amazon S3, DynamoDB, Redshift y Kinesis.
  
• El Servicio de Almacenamiento Simple de Amazon (Amazon S3), es nuestro servicio de almacenamiento de objetos que brinda a los desarrolladores y equipos de TI, un almacenamiento seguro, duradero y escalable en la nube.
  
  S3 se utiliza para admitir una amplia variedad de casos de uso y es fácil de usar con una interfaz simple para almacenar y recuperar cualquier cantidad de datos. En el caso de nuestra aplicación de chat para sobrevivientes, incluso se puede usar para alojar sitios web estáticos con soporte CORS y DNS.
  
• Amazon API Gateway facilita la creación de "RESTful API" para sus aplicaciones. API Gateway es escalable y fácil de configurar, lo que le permite crear integraciones con aplicaciones de servicios de fondo, incluido el código que se ejecuta en AWS Lambda, mientras el servicio maneja la escala de sus solicitudes de la API.
  
• Amazon DynamoDB es un servicio de base de datos NoSQL rápido y flexible, para todas las aplicaciones que necesitan una latencia de milisegundos consistente y de un solo dígito en cualquier escala. Es una base de datos en la nube totalmente administrada y es compatible con los modelos de almacenamiento de documentos y valores clave. Su modelo de datos flexible y su rendimiento confiable lo hacen ideal para dispositivos móviles, web, juegos, tecnología publicitaria, IoT y muchas otras aplicaciones.

Descripción general de la aplicación Zombie Survivor Chat

La aplicación "Chat Survivor" representa una arquitectura completamente sin servidor, que ofrece una aplicación de chat de referencia (escrita usando AngularJS) a los participantes del taller, sobre la cual se puede agregar funcionalidad adicional.

Para entregar esta aplicación de chat de línea de base, se les proporciona a los participantes una plantilla de AWS CloudFormation, que activa el ambiente en sus cuentas. El siguiente diagrama representa una arquitectura de alto nivel de los componentes que se inician automáticamente:

• El cubo de Amazon S3 se creó para almacenar los contenidos de la aplicación web estática de la aplicación de chat.
  
• Las funciones de AWS Lambda se crean para servir como el nivel lógico de negocio de back-end, para procesar las lecturas/escrituras de los mensajes de chat.
  
• Los puntos finales API se crean utilizando API Gateway y se asignan a las funciones de Lambda. El método API Gateway POST apunta a una función WriteMessages Lambda. El método GET apunta a una función Lambda GetMessages.
  
• Se aprovisiona una tabla de mensajes DynamoDB para actuar como nuestro almacén de datos para los mensajes de la aplicación de chat.

Con la pila CloudFormation lanzada y los componentes construidos, el resultado final es una aplicación de chat totalmente funcional alojada en S3, que utiliza API Gateway y Lambda para procesar solicitudes, y DynamoDB como persistencia para nuestros mensajes de chat.

Con esta aplicación de referencia, los participantes se unen en equipos para desarrollar funcionalidades adicionales, que incluyen lo siguiente:

• Integración de SMS/MMS a través de Twilio. Enviar mensajes para chatear desde SMS.
  
• Detección del sensor de movimiento de zombies cercanos con Amazon SNS e Intel® Edison y Grove IoT Starter Kit. AWS proporciona un sensor de movimiento compartido para el taller y usted consume sus mensajes del SNS.
  
• Ayuda con botón de pánico con IoT.
  
• Integración con Slack para mensajes desde otra plataforma.
  
• Indicador de escritura para ver qué sobrevivientes están escribiendo.
  
• Análisis sin servidor de mensajes de chat utilizando Amazon Elasticsearch Service (Amazon ES).
  
• ¡Cualquier otra funcionalidad en la que los participantes puedan pensar!

Como parte del taller, AWS brinda orientación para la mayoría de estas tareas. Con estos complementos, la arquitectura del sistema de chat comienza a parecer un poco más sofisticada, como se muestra a continuación:

Inquilinos arquitectónicos del Chat de supervivientes sin servidor

En su mayor parte, los patrones de diseño que veríamos en un entorno tradicional de servidor, si también lo encontrarás en un entorno sin servidor. No hay sorpresas allí. Dicho esto, nunca está de más repasar las mejores prácticas mientras se aprenden otras nuevas. Repasemos algunos patrones clave que incorporamos en nuestra aplicación sin servidor.

El desacoplamiento es primordial

En la aplicación de "Chat Survivor", las funciones de Lambda sirven como nuestro nivel para la lógica de negocios. Dado que los usuarios interactúan con Lambda en el nivel de función, le sirve para dividir la lógica en funciones separadas, tanto como sea posible para que pueda escalar el nivel lógico independientemente de la fuente y los destinos en los que se sirve.

Como verá en el diagrama de arquitectura en la sección anterior, la aplicación tiene funciones Lambda separadas para el servicio de chat, el servicio de búsqueda, el servicio de indicadores, etc.

El desacoplamiento también se incorpora mediante el uso de API Gateway, que expone nuestra lógica de back-end a través de una interfaz RESTful unificada. Este modelo nos permite diseñar nuestra lógica de back-end con lenguajes de programación, sistemas o canales de comunicación potencialmente diferentes, a la vez que mantenemos a los puntos finales solicitantes al margen de la implementación.

Utilice este patrón y no llorará solicitando ayuda cuando necesite escalar, actualizar, agregar o eliminar piezas de su entorno.

Separe sus almacenes de datos

Trate cada almacén de datos como un componente de aplicación aislado del servicio al que da soporte. Un inconveniente común cuando se siguen arquitecturas de microservicios es olvidarse de la capa de datos.

Al mantener los almacenes de datos específicos para el servicio que admiten, puede administrar mejor los recursos necesarios en la capa de datos específicamente para ese servicio. Este es el verdadero valor en microservicios.

En la aplicación "Chat Survivor", esta práctica se ilustra con las tablas DynamoDB Activity y Messages. El servicio indicador de actividad tiene su propio almacén de datos (tabla de actividades) mientras que el servicio de chat tiene el suyo (mensajes).

Estas tablas pueden escalarse independientemente junto con sus respectivos servicios. Este escenario también representa un buen ejemplo de statefuless. La implementación del complemento de indicador de conversación utiliza DynamoDB a través de la tabla de Actividad, para rastrear la información de estado acerca de qué usuarios están hablando.

Recuerde que muchos de los beneficios de los microservicios se pierden, si los componentes todavía están pegados en la capa de datos al final, creando un denominador común desordenado para escalar.

Aproveche las transformaciones de datos

Al diseñar un servicio, la transformación de datos y la compatibilidad son componentes importantes.

¿Cómo manejará las entradas de muchos clientes, usuarios y sistemas diferentes para su servicio? ¿Ejecutará diferentes sabores de su entorno para que se correspondan con los diferentes estándares de solicitud entrante? ¡Absolutamente no!

Con API Gateway, la transformación de datos se vuelve significativamente más fácil a través de modelos incorporados y plantillas de asignación. Con estas características, puede construir transformación de datos y lógica de mapeo en la capa API para solicitudes y respuestas.

Esto resulta en menos trabajo para usted, ya que API Gateway es un servicio administrado. En el caso de nuestra aplicación de chat para sobrevivientes, AWS Lambda y nuestra aplicación de chat para sobrevivientes requieren JSON, mientras que a Twilio le gusta XML para la integración de SMS. Este tipo de transformación se puede descargar a API Gateway, dejándolo con un nivel empresarial más limpio y una cosa menos para diseñar.

Use API Gateway como su interfaz y Lambda como su implementación de back-end común. API Gateway utiliza Apache Velocity Template Language (VTL) y JSONPath para lógica de transformación.

Por supuesto, hay que considerar una compensación, ya que se podría manejar mucha lógica de transformación en su nivel lógico de negocios (Lambda). Pero, ¿por qué administrarlo usted mismo en el código de la aplicación, cuando puede manejarlo de forma transparente en un servicio completamente administrado a través de API Gateway?

Aquí hay algunas cosas a tener en cuenta al manejar transformaciones usando API Gateway y Lambda:

• Transformar primero; luego llame a su lógica común de back-end.
  
• Utilice las transformaciones VTL de puerta de enlace de API primero cuando sea posible.
  
• Use Lambda para preprocesar datos de formas que VTL no puede.

Seguridad a través del aislamiento del servicio y el mínimo privilegio

Como recomendación general al diseñar sus servicios, siempre utilice los privilegios mínimos y aísle los componentes de su aplicación para proporcionar control sobre el acceso. En la aplicación "Chat Survivor", se utiliza un modelo basado en permisos a través de AWS Identity and Access Management (IAM).

IAM está integrado en todos los servicios de la plataforma AWS y brinda la capacidad para que los servicios y las aplicaciones, asuman roles con conjuntos de permisos estrictos para realizar sus necesidades de acceso con menos privilegios.

Junto con los controles de acceso, debe implementar el registro de auditoría y acceso para proporcionar la mejor visibilidad en sus microservicios. Esto es más fácil con Amazon CloudWatch Logs y AWS CloudTrail.

CloudTrail habilita la capacidad de auditoría de las llamadas API realizadas en la plataforma, mientras que CloudWatch Logs le permite enviar datos de registro personalizados a AWS.

Aunque nuestra implementación de Amazon Elasticsearch en el chat de supervivientes se utiliza para analizar mensajes de chat, puede enviar fácilmente sus datos de registro y realizar análisis en su aplicación. Puede incorporar las mejores prácticas de seguridad de las siguientes maneras con la aplicación de chat de supervivientes:

• Cada función de Lambda debe tener un rol de IAM para acceder solo a los recursos que necesita. Por ejemplo, la función GetMessages puede leer de la tabla Messages mientras que la función WriteMessages puede escribir en ella.
  
  Pero no pueden acceder a la tabla de Actividades que se usa para rastrear quién está escribiendo para el servicio de indicadores.
  
• Cada punto final de la Pasarela API debe tener permisos IAM para ejecutar la(s) función(es) Lambda a la que está vinculado. Este modelo asegura que Lambda solo se ejecuta desde el principio que está permitido ejecutarlo, en este caso el método API Gateway que desencadena la función back-end.
  
• DynamoDB requiere permisos de lectura/escritura a través de IAM, lo que limita la actividad anónima de la base de datos.
  
• Utilice AWS CloudTrail para auditar la actividad API en la plataforma y entre los diversos servicios. Esto proporciona trazabilidad, especialmente para ver quién está invocando sus funciones de Lambda.
  
• Diseñe las funciones de Lambda para publicar resultados significativos, ya que estos se registran en los registros de CloudWatch en su nombre.

Para su información, en nuestra aplicación, permitimos el acceso anónimo a los puntos finales de la Pasarela API de chat. Queremos alentar a todos los sobrevivientes a conectarse al servicio sin registro previo y comenzar a comunicarse.

Supusimos que los zombis no son lo suficientemente inteligentes como para hackear nuestros canales de comunicación. Hasta el apocalipsis sin embargo, manténgase fiel a las claves de la API y la autorización con firmas, ¡que es compatible con API Gateway!

No abandonemos Prueba/Desarrollo

Al desarrollar con microservicios, puede aprovechar entornos de prueba y desarrollo independientes como parte del ciclo de vida de la implementación. AWS proporciona varias funciones para ayudarlo a continuar creando aplicaciones en la misma trayectoria que antes, incluyendo:

• Versiones y alias de la función Lambda: utilice estas funciones para versionar sus funciones en base y con apego a las etapas de implementación como desarrollo, prueba, puesta en escena, preproducción, etc. O tal vez realice cambios en una función Lambda existente en producción sin tiempo de inactividad.
  
• Planos del servicio Lambda: Lambda viene con docenas de planos para que pueda comenzar con el código preescrito que puede usar como esqueleto, o como una solución completamente funcional para completar su back-end sin servidor. Estos incluyen planos con enlaces a Slack, S3, DynamoDB y más.
  
• Etapas de implementación de API Gateway: Similar a la versión de Lambda, esta característica le permite configurar etapas API separadas, junto con variables de etapa únicas y versiones de implementación dentro de cada etapa. Esto le permite probar su API con los mismos o diferentes back-ends, mientras avanza a través de los cambios que realiza en la capa API.
  
• Integración de Maquetas con API Gateway: configure las respuestas ficticias que los desarrolladores pueden usar, para probar su código mientras se desarrolla la verdadera implementación de su API. Las integraciones simuladas (maquetas) hacen que sea más rápido iterar a través de la porción API de un ciclo de vida de desarrollo, mediante la racionalización de piezas que solían ser muy secuenciales y/o en cascada.

¡Manténgase atento a las actualizaciones!

Asegúrese de estar atento al repositorio de AWS GitHub. Aunque no cubrimos cada componente de la aplicación de "Chat Survivor" en esta publicación, ¡vamos a implementar este taller y código pronto para que pueda iniciarse por su cuenta! Esté atento a los Talleres Zombies que se acercan a su ciudad, o designe su ciudad para un taller aquí.

18 herramientas para Big Data que necesitas conocer!!!

En el ámbito de la Transformación Digital de hoy en día, Big Data ha brindado a la organización una ventaja para analizar el comportamiento del cliente e hiper-personalizar cada interacción que resulta en ventas cruzadas, una mejor experiencia del cliente y obviamente más ingresos.

El mercado de Big Data ha crecido constantemente a medida que más y más empresas han implementado una estrategia basada en datos. Si bien Apache Hadoop es la herramienta más establecida para analizar Big Data, existen miles de herramientas de big data por ahí. Todas ellas prometen ahorrarle tiempo, dinero y ayudarlo a descubrir conocimientos empresariales nunca antes vistos.

Hemos seleccionado algunos para que comience con  Big Data con el pie derecho:

Avro: fue desarrollado por Doug Cutting y utilizado para la serialización de datos para codificar el esquema de los archivos de Hadoop.

Cassandra: es una base de datos distribuida y de código abierto. Diseñada para manejar grandes cantidades de datos distribuidos en servidores de productos básicos, a la vez que proporciona un servicio altamente disponible. Es una solución NoSQL que fue desarrollada inicialmente por Facebook. Es utilizado por muchas organizaciones como Netflix, Cisco, Twitter, así como formar parte de los Servicios de Nutanix, dentro de la Controler Virtual Machine.

Drill: un sistema distribuido de código abierto para realizar análisis interactivos en conjuntos de datos a gran escala. Es similar al Dremel de Google y es administrado por Apache.

Elasticsearch: un motor de búsqueda de código abierto basado en Apache Lucene. Está desarrollado en Java y puede impulsar búsquedas extremadamente rápidas, que respalden sus aplicaciones de descubrimiento de datos.

Flume: es un marco para poblar Hadoop con datos de servidores web, servidores de aplicaciones y dispositivos móviles. Es la fontanería entre las fuentes y Hadoop.

HCatalog: es un servicio centralizado de administración y uso compartido de metadatos para Apache Hadoop. Permite una visión unificada de todos los datos en los clústeres de Hadoop y permite que diversas herramientas, incluyendo Pig y Hive, procesen cualquier elemento de datos sin necesidad de saber físicamente en qué parte del clúster se almacenan los datos.

Impala: proporciona consultas SQL rápidas e interactivas directamente en sus datos de Apache Hadoop almacenados en Hadoop Distributed File System (HDFS) o HBase utilizando los mismos metadatos, la sintaxis SQL (Hive SQL), el controlador ODBC y la interfaz de usuario (Hue Beeswax) como Apache Hive. Esto proporciona una plataforma familiar y unificada para consultas orientadas a lotes o en tiempo real.

JSON: muchas de las bases de datos NoSQL de hoy almacenan datos en el formato JSON (JavaScript Object Notation) que se ha hecho popular entre los desarrolladores web. JSON también es altamente popular en todas aquellas soluciones que manejan REST-API para administración vía interfaz navegador.

Kafka: es un sistema distribuido de mensajería de publicación y suscripción, que ofrece una solución capaz de manejar toda la actividad del flujo de datos y procesar éstos en un sitio web del consumidor. Este tipo de datos (visitas a la página, búsquedas y otras acciones del usuario) son un ingrediente clave en la web social actual.

MongoDB: es una base de datos NoSQL orientada a documentos, desarrollada bajo el concepto de Código Abierto. Esto viene con soporte para indexado completo, flexibilidad para indexar cualquier atributo y escalar horizontalmente sin afectar la funcionalidad.

Neo4j: es una base de datos de gráficos y cuenta con mejoras de rendimiento de hasta 1000 veces o más, cuando se compara con bases de datos relacionales.

Oozie: es un sistema de procesamiento de flujo de trabajo que permite a los usuarios definir una serie de trabajos escritos en varios idiomas, como Map Reduce, Pig y Hive. Además, los vincula inteligentemente entre sí. Oozie permite a los usuarios especificar dependencias.

Pig: es un lenguaje basado en Hadoop desarrollado por Yahoo. Es relativamente fácil de aprender y es un lenguaje experto para los canales de datos muy profundos y muy extensos.

Storm: es un sistema de computación distribuida en tiempo real, de código abierto y gratuito. Storm facilita el procesamiento fiable de flujos de datos no estructurados en el campo del procesamiento en tiempo real. Storm es tolerante a fallas y funciona con casi todos los lenguajes de programación, aunque típicamente lo han utilizado con Java. Descendiendo de la familia Apache, Storm ahora es propiedad de Twitter.

Tableau: es una herramienta de visualización de datos con un enfoque principal en la inteligencia empresarial. Puede crear mapas, gráficos de barras, diagramas de dispersión y más, sin necesidad de programación. Recientemente lanzaron un conector web que le permite conectarse a una base de datos o API, lo que le brinda la posibilidad de obtener datos en tiempo real en una visualización.

ZooKeeper: es un servicio que proporciona configuración centralizada y registro de nombre de código abierto para grandes sistemas distribuidos. ZooKeeper es uno de los servicios fundamentales dentro de la Controler Virtual Machine de Nutanix.

Todos los días se agregan muchas más herramientas, la pila de tecnología Big Data y es extremadamente difícil de lidiar con todas y cada una de las herramientas. La recomendación aquí yu ahora es que Usted seleccione algunas que pueda dominar y continúe actualizando su conocimiento.

¿Ya aplica alguna de estas herramientas para la estrategia de Big Data en su empresa u organización?