Amazon lo quiere todo: Amazon IOT

Asistí la semana pasada al evento de Amazon Web Services en Barcelona, y me quedé francamente sorprendido con lo que se presentó allí. Hubo anuncios sobre nuevas herramientas de gestión (Amazon Cloudwatch Dashboards o las nuevas AWS config rules), seguridad (amazon WS WAF y Amazon Inspector), análisis y Big Data (Amazon Quicksight), Bases de datos (múltiples anuncios), la disponibilidad de Hosts dedicados (algo realmente innovador en Amazon), las nuevas instaciones X1 (pensadas para SAP HANA), el servicio de carga de datos (con un appliance Snowball) o el rompedor AWS Lambda, para automatización de tareas en los entornos de computación (basado en Python). Pero lo que más me sorprendió, con diferencia, fue la nueva arquitectura AWS IOT (Internet of Things), que permitirá la construcción y despliegue rápido de redes sensorizadas de "cosas", que recogerán datos, los procesarán y tomarán decisiones (algunas basadas en Lambda) con un coste de infraestructura ridículo, y con capacidad de gestionar millones de dispositivos y de mensajes generados por estos.

AWS IOT permite recibir mensajes en formato HTTP 1.1 y MQTT (protocolo de comunicación ligero diseñado para mensajes cortos y conexiones intermitentes) a través del dispositivo virtual AWS Device Gateway.
El motor de reglas permite compilar aplicaciones IoT para recabar, procesar, analizar y utilizar datos generados por dispositivos conectados a escala global sin tener que administrar ninguna infraestructura. El motor de reglas evalúa los mensajes entrantes publicados en AWS IoT y los transforma y entrega en otro dispositivo o en un servicio de la nube, conforme a las reglas empresariales establecidas. Una regla se puede aplicar a los datos de uno o varios dispositivos, y puede ejecutar una o varias acciones en paralelo.

Puede crear reglas en la consola de administración o escribirlas con una sintaxis tipo SQL. Las reglas se pueden crear de tal forma que se comporten de manera distinta, en función del contenido del mensaje. Por ejemplo, si una lectura de temperatura excede un umbral determinado, podría activar una regla para transmitir datos a AWS Lambda. Las reglas también se pueden crear para que tengan en cuenta otros datos en la nube, como los datos de otros dispositivos. Por ejemplo, puede dictar que se ejecute una acción si la temperatura es superior al 15% de la media de otros cinco dispositivos.

El motor de reglas ofrece docenas de funciones disponibles que pueden utilizarse para transformar los datos, y se pueden crear más de manera indefinida a través de AWS Lambda. Por ejemplo, si va a trabajar con un amplio abanico de valores, podría calcular la media de los números entrantes. Las reglas también pueden activar la ejecución de código Java, Node.js o Python en AWS Lambda, aportándole máxima flexibilidad y potencia para procesar los datos de los dispositivos.

Los costes parecen muy razonables, no hay coste de entrada y el pago es por uso, básicamente de publicación y de envío de mensajes. Se comentaron varios ejemplos, aunque a mi me resultó particularmente útil de los 100 sensores que envían un mensaje de 400 bytes/minuto, que se envían a otro dispositivo y se almacenan en una Base de Datos no SQL (DynamoDB). EL coste mensual sería de 43,00 USD en Europa.

La capa gratuita de AWS IoT permite comenzar con 250 000 mensajes (bloque de datos de 512 bytes) gratuitos (publicados o enviados) al mes durante 12 meses. AWS IoT no cobra por la entrega a los siguientes servicios de AWS: Amazon S3, Amazon DynamoDB, AWS Lambda, Amazon Kinesis, Amazon SNS y Amazon SQS.

Lo cierto es que, al margen de las prestaciones, lo importante es que es una plataforma para desarrolla rápido y a un coste mínimo de todo tipo de aplicaciones IOT, lo que permitirá acelerar la puesta en marcha de muchos proyectos empresariales muy innovadores. Gracias Amazon. Es una beta, pero o dudamos de que pronto será una realidad muy tangible.

Más información en: https://aws.amazon.com/es/iot/

Resilience

Un término que se ha ido poniendo de moda, es "IT Resilience". Su definición es "Data center resiliency is the ability of a server, network, storage system, or an entire data center, to continue operating even when there has been an equipment failure, power outage or other disruption.".  Su origen viene de la física, como la capacidad de un material de absorber energía (de un choque, una deformación) y volver a su posición inicial. Todos ellos son pinceladas que alumbran el motivo del "post", que es hablar un poco sobre la capacidad que tienen nuestros sistemas informáticos de sobrevivir a un desastre.

Tengo un amigo que dice que Murphy se pasea en bicicleta por los pasillos de un Datacenter, y es verdad. Todo aquello que puede ir mal, irá mal y peor. Y por ello, es bueno anticiparse, y probar los sistemas. Y esto último es lo que se hace poco: ensayar y probar nuestra capacidad de "Resilience", para ver si es real o simplemente se siguió un manual para implantarla y ya está. 

A lo largo de mi carrera, he visto muchos CPDs, muchas instalaciones, y debo decir, que esta capacidad de "Resilience", es un tigre de papel. Muchos CIOs están apagando fuegos a cuatro manos, y si les preguntas sobre su "Resilience", arquean los ojos, te miran con cariño, y te contestan otra cosa. Y es lógico. Llevamos ya muchos años de crisis y de restricciones, pero también de explosión de la importancia de los sistemas, sin ellos casi ninguna empresa existiría. Y sin embargo, pocos valoran la posibilidad de preparar un desastre, probando sus capacidades, con un simulacro controlado. 

Por ello, me ha gustado este artículo de la preparación de Netflix ante una caída seria de Amazon, su proveedor Cloud. Leedlo y me decís qué pensáis... 

Revista CIO, 3/10/2014.

Sometimes the best path to success is to learn how to avoid failure.

Netflix was able to keep serving its customers while its cloud hosting provider, Amazon Web Services (AWS), rebooted servers, because it had prepared for that happening.

“When we got the news about the emergency EC2 [Elastic Cloud Compute] reboots, our jaws dropped. When we got the list of how many Cassandra nodes would be affected, I felt ill,” said Christos Kalantzis, Netflix engineering manager of cloud database engineering, in a Netflix blog post discussing the outage.

Amazon announced to EC2 customers on Sept. 25 that it would be updating its servers and that a small percentage would require a reboot, which could potentially disrupt customer services. AWS did not specify which of their virtual hosts would be rebooted or when. It was revealed later that AWS was fixing a vulnerability in the Xen hypervisor, which underpins EC2.

Netflix is one of Amazon’s largest customers. And its 50 million customers expect to be able to stream TV shows, movies and other content at any time. If Netflix wasn’t prepared to mitigate potential outages, the company—and not Amazon—would have a lot of angry customers.

But Netflix had architected its service to be resilient, so that if one Amazon data center went down, operations could be switched over to another with barely a noticeable bump to customers. It also looked for ways to minimize downtime that occurred when its services did need to be rebooted.

The company even went the extra mile and aggressively looked for ways to try to disrupt its own services through a set of tools called the Simian Army that are designed to periodically and randomly kill Netflix services. The thinking goes that any Netflix service should be resilient enough to keep running through an attack from one such tool. If it isn’t, then the Netflix engineers redesign the service to make it more reliable.

Even with its systems hardened by abuse from Chaos Monkey and other Simian Army tools, the engineers were still worried about the AWS reboot.

In particular, concern centered around the 2,700 Cassandra databases that the company runs on AWS.

Databases, as the blog post pointed out, are “the pampered and spoiled princes of the application world.” They are run on the best hardware, get lots of attention from database engineers and still can be fussy creatures.

Netflix deliberately chose to use the Cassandra database over more traditional choices such as Oracle’s databases because, as a NoSQL database, Cassandra could be spread across multiple servers in such a way that if one of the nodes failed, the database could keep running. Over the past year, the company had been subjecting Cassandra to Chaos Monkey testing, with promising results.

The AWS reboot would be the first true test of Cassandra’s reliability, however. The entire cloud database engineering team was on alert.

In the end, and thanks to Chaos Monkey testing, most all of the Cassandra nodes remained online. Of the 218 Cassandra nodes that were rebooted, only 22 did not return to a full operational state, and those were successfully restarted with minimal human intervention.

“Repeatedly and regularly exercising failure, even in the persistence layer, should be part of every company’s resilience planning,” the blog concluded. “If it wasn’t for Cassandra’s participation in Chaos Monkey, this story would have ended much differently.”