Si eres tester, seguro que esto te va a encantar… y si no, casi que también. La curiosidad mató al gato y la Curiosity podía matar los servidores de la NASA si mucha gente quería seguir en directo, vía streaming, el aterrizaje del nuevo robot espacial de la familia Mars Rover en Marte, el planeta rojo, que se iba a realizar (como así fue) en la noche del pasado domingo (madrugada del lunes en España). Por eso tuvieron mucho cuidado en testear todo el sistema y ahora podemos seguir los pasos y las herramientas que siguieron y utilizaron.

• Para empezar el streaming lo alojaron de manera externa, en la nube de los Amazon Web Services, y recurrieron a la ayuda de los expertos en testing en la nube de SOASTA.
• La infraestructura del test se centralizó en un sólo servidor de origen (un Mac Pro sito en los laboratorios de la NASA) sirviendo cuatro bitrates de 250, 500, 7500 y 1000 a un servidor de Flash Media. La salida estaba cacheada mediante un servidor Nginx (para el tier 1) enfrentado a 40 balanceadores de carga (nivel tier 2) corriendo sobre Amazon EC2.
• De esta manera SOASTA consiguió generar 25 Gigas por segundo durante 40 minutos.
• A los 20 minutos cerraron diez instancias para comprobar que la nube de Amazon podría soportar una situación de este tipo. Esto redujo el tráfico que se podía soportar pero a los 5 minutos y gracias al balanceador de carga elástico de Amazon, el sistema volvía a ser capaz de manejar los 25 Gbps.
• Lo siguiente fue cerrar 20 instancias y, aunque al principio fue duro (cantidad de tráfico soportado a la mitad, claros signos de sobrecarga…), el sistema consiguió recuperarse y volver al estado inicial.

Más de 68TB de vídeo fueron descargados durante estos 40 minutos de prueba. En definitiva, una señora prueba que dio unos resultados positivos que luego fueron refrendados durante la retransmisión del evento. Obviamente no todos pueden montar pruebas de este calibre pero siempre es bueno saber como funcionan los grandes para intentar escalarlo a tu nivel o simplemente inspirarte un poco.

Pd1: encabezando el post, la primera imagen a color tomada por la Mars Rover Curiosity en Marte.

Pd2: gráficas de rendimiento bastante interesantes en el post original.

Vía | Gigaom
Foto | NASA
En Genbeta Dev | Lecciones aprendidas del testing de aplicaciones software

Al desarrollar una aplicación Android es tan importante la implementación de la aplicación como la de la parte servidor que usaremos para diferentes tareas como la autenticación de usuarios, servir contenido como imágenes o datos, usar una base de datos centralizada, etc.. Para ello, seguramente, si usamos algún servicio en la nube como Amazon quizás nos interese usar el SDK de Amazon Web Service para Android.

El SDK de Amazon Web Service para Android provee un conjunto de librerías, ejemplos y documentación para que los desarrolladores puedan construir aplicaciones móviles que usen los servicios en la nube de Amazon como Amazon S3, Amazon EC2, Amazon SimpleDB, CloudFront, Amazon RDS, Amazon SQS o Amazon SNS.

Normalmente, cuando queremos usar servicios en la nube debemos implementar nuestras propias librerías que manejen las peticiones HTTP, abran y cierren las conexiones y empaquetar cada uno de los parámetros necesarios. AWS SDK nos permite utilizar distintos servicios en la nube desde la misma aplicación cuando lo necesitemos

• Almacenamiento: usando Amazon S3 para los datos, tanto para servir contenido o almacenar datos enviados desde la aplicación móvil.
• Bases de datos: con SimpleDB disponemos de una base de datos clave-valor escalable para almacenar todos los datos que queramos desde la aplicación.
• Computación en la nube: podemos lanzar y manejar instancias de Amazon EC2.
• Mensajería: podemos usar Amazon SQS y Amazon SNS para integrar un sistema de comunicación móvil para nuestra aplicación y enviar mensajes broadcast.

Así, ya estemos desarrollando una aplicación multimedia que necesite fotos usando Amazon S3, un juego online que interactue con distintas bases de datos escalable o un sistema de mensajería entre aplicaciones podemos usar el Amazon Webservices SDK para Android para interactuar con los servicios en la nube fácilmente.

Descarga y documentación | SDK Amazon Web Services para Android
Más información | Develop Android Apps with Amazon Web Services

Al alojar nuestra flamante nueva aplicación web, una de las primeras cosas que deberemos hacer es seguramente registrar los nombres de host que se utilizarán para el dominio en cuestión en un servicio DNS. Hay veces que el registrador de dominio nos provee de un servicio básico, aunque éste suele ser deficiente (hay que tener en cuenta que pagamos poco o nada por él). En la mayoría de casos, es el proveedor de hospedaje quien nos lo proporciona, pero si estamos utilizando un VPS o un servicio en la nube para servir nuestra aplicación, lo más seguro es que tengamos que recurrir a los servicios de un tercero para poder dar respuesta a las peticiones DNS acerca de nuestro dominio.

Si tu aplicación se aloja en Amazon EC2, seguramente preferirás tener toda tu infraestructura en la nube de Amazon, y esto incluye cómo no el servicio de DNS. Y aquí es donde cobra protagonismo Amazon Route 53.

Gracias a este servicio, podremos gestionar los registros DNS correspondientes a los dominios de nuestras aplicaciones a través tanto de una interfaz web como de un API (para poder automatizar la manipulación de dichos registros). Los tipos de registro DNS soportados son: A, AAAA (registro address para IPv6), CNAME, MX, NS, PTR, SOA, SPF, SRV, y TXT.

El coste del servicio está bastante ajustado: 1 dólar al mes por cada zona, y 0,50 dólares cada millón de peticiones (los primeros mil millones de peticiones del mes, luego a 0,25 dólares cada millón).

Sitio oficial | Amazon Route 53
Documentación | Documentación

Los servicios de Amazon en la nube son fiables, es posible asegurar un 99% de uptime (aunque asumimos casi tres días de caída). Muchas veces esas caídas son algún fallo ocasional que no dura más de unos minutos seguidos, pero ayer Amazon EC2 experimentó la mayor caída del servicio al producirse graves problemas en los servidores basados en el Norte de Virginia. No se cayó el servicio a nivel mundial, pero la repercusión fue importante al afectar a numerosos proyectos de empresas de internet, desde startup a algunas que ya no lo son tanto como Foursquare, Quora, Reddit o Hootsuite, incluso servicios como Heroku que actúan de servidores en la nube a otros. El listado completo se puede ver en una web creada a tal efecto, #ec2disabled.

El compromiso del contrato a nivel de servicio de Amazon EC2 es de una disponibilidad del 99,95% en cada Región de Amazon EC2.

Cuando cedemos nuestra infraestructura de servidores a una empresa externa, sea la nube, un hosting o lo que sea, asumimos este tipo de fallos. Los críticos a los servicios a la nube pueden aprovechar este incidente para reclamar que aunque ahorremos dinero, tiempo, esfuerzo y ganemos escalabilidad no estamos a salvo de fallos inesperados. Ni mucho menos evitar preguntarnos cuando se restablecerá el servicio. Empresas que tienen miles de maquinas alojadas en EC2 pueden experimentar momentos de pánico al no saber que pasa con sus servicios. Si normalmente al detectar un pico de tráfico somos capaces de enviar con rapidez y anticipación nuevas instancia, aquí es complicado responder a tiempo.

Desde hace un tiempo Amazon EC2 está experimentando fallos en sus servidores como podemos contemplar en los paneles de status, el dashboard de Amazon Web Services. Errores sobre todo en Elastic Beanstalk, y la base de datos relacional, Cloudwatch entre otros. Problemas de conectividad entre instancias que no gustan nada a los desarrolladores, menos cuando nos estamos acostumbrando a desplegar y punto, olvidándonos de configurar maquinas.

Cuando hay nubes, a veces llueve. Por eso a raíz de las recientes interrupciones de servicio estaría bien seguir una serie de ideas para mantener los servicios hospedados disponibles durante las caídas masivas de los servidores alojados en la nube.

¿Tenéis alguna alternativa más en caso de caída masiva de nuestros servicios en la nube?

Vía | All Things Digital
Más información | Status Dashboard Amazon Web Services, EC2Disabled

Una de las principales preocupaciones cuando llevamos nuestros datos a la nube (cloud computing) es la privacidad de esos datos y evitar que sean comprometidos. Un motivo importante por el cual la empresas son recelosas de usar servicios en la nube cuando se trata de su base de datos o documentos confidenciales. Hay método de encriptación, pero ahora la nueva versión del SDK de AWS para Java trae una importante funcionalidad para encriptar los datos desde el lado del cliente de forma automática cuando usamos Amazon S3 para almacenar datos.

Una vez activada la encriptación, el SDK encripta automáticamente los datos antes de enviarlos a Amazon S3 y los desencripta antes de retornar los datos a la aplicación. Esta funcionalidad nos ofrece total control a la hora de que keys usar y estas nunca son transmitidas por la red.

Nuestras llamadas al SDK de AWS de java incluye una Master Key. La key es usada para en sellar nuestra clave generada con el SDK. Esa clave es la que se usa para encriptar la Master Key y los datos antes dejárselos al cliente.

Además, el SDK de Amazon incluye numerosas opciones de configuración, incluyendo la posibilidad de la encriptación simétrica y asimétrica. Se puede elegir almacenar la envelope key como un metadato del objeto S3 o como un objeto S3 individual.

Vía | Amazon Web Service Blog
Más información | SDK AWS para Java, Amazon S3

Recientemente, Amazon lanzó CloudFormation con el objetivo de simplificar la integración de pilas de recursos que se usen en Amazon Web Services (AWS) tanto para los desarrolladores como los administradores de sistemas. Podemos mantener las configuración, distribuir tareas y la gestión de las notificaciones de la plataforma por medio de unos templates sencillos que definen el comportamiento de nuestra configuración.

Uno de los inconvenientes de que nuestro desarrollo crezca es la complejidad que adquiere para manejar la escalabilidad y la gestión de errores de la plataforma. Amazon Web Services ofrece cada vez más servicios ya que lejos usar sólo instancias Amazon EC2 o en buckets Amazon S3, sino que vamos incorporando los servicios que Amazon continua lanzando (a veces, como si nos leyera la mente) como Amazon Simple Notification Service (SNS), Amazon Relational Database Service (RDS) o los Elastic Load Balancers. Casi una decena de servicios que debemos gestionar cada vez que queramos escalar nuestra aplicación.

CloudFormation hace fácil la organización de esa colección de recursos de AWS que queremos desplegar y permite describir las dependencias y parámetros especiales de cada rutina. Para manejar esas configuraciones Amazon ha creado templates predefinidas a partir de las cuales nos podemos basar para desplegar nuestros servicios en la nube. Hay template de ejemplo para Wordpress (blog), Drupal (CMS), Tracks (project tracking), Joomla(CMS), MoinMoin (wiki), Hibari (wiki), MantisBT(bug tracker), etc… y muchas más que se irán incorporando al repositorio de templates.

Las ventajas de CloudFormation son claras: no es necesario reinventar la rueda ya que con los templates podemos replicas copias idénticas de la misma pila de recurso que usen nuestras aplicaciones, las templates se escriben en formato JSON por lo que son bastante claras de leer y configurar, flexible al declarar los recursos que vamos a necesitar y acomodarlos a nuestras intereses y, por último, para utilizarlo no tenemos que pagar más sino que el pago se factura según el gasto de los recursos que usemos como hasta ahora. Realmente es un añadido bastante útil que aclarará muchas configuraciones de aplicaciones que estén ejecutándose en cloud computing.

La formación relacionada la podemos encontrar en la documentación oficial. Además Amazon Web Service realizará un webinar sobre CloudFormation el día 1 de Abril a las 11 de la mañana (hora española) en la que podemos aprender más.

Vía | AWS Blog
Más información | CloudFormation, Repositorio de Template, Webinar CloudFormation

Posiblemente la siguiente revolución de la programación en la nube sea las bases de datos. Su futuro puede estar cerca de convertirse en un servicio más al que recurramos cuando necesitemos un fácil acceso y escalable contenedor de datos para olvidarnos de las complicaciones técnicas de instalación y despliegue en nuestros desarrollos.

Las DbaaS son simples de usar, no requiere que los usuarios realicen gestión a bajo nivel, tales como parches, copias de seguridad o configuración. Además se puede ajustar el rendimiento basándose a los requerimientos precisamos antes picos de tráfico. Nos podemos aprovechar de los administradores de sistemas que disponen las compañías que proveen bases de datos en la nube para despreocuparnos y centrarnos en el desarrollo de nuestra aplicación.

Actualmente existen un amplio abanico de bases de datos como servicio (Dbaas) que se va incrementando, lo que confirman que el futuro de las bases de datos está en la nube.

Amazon es un claro exponente de hacía donde se encaminan los servicios en la nube, cada cierto tiempo lanza un servicio. Entre los ellos destacamos Amazon Relational Database Service (RDS) que provee lo que comentábamos anteriormente, sin tener que crear una base de datos en una instancia EC2 podemos acceder a sus bases de datos para interactuar desde nuestras instancias en AWS. Recientemente anunció planes para ofrecer una versión de Oracle que, incluso, las empresas que ya dispongan de una licencia de la base de datos podría usar. Interesante.

Xeround, es una startup dedicada en ofrecer bases de datos MySQL personalizadas que se ejecuten en aplicaciones en AWS. Recientemente anunció que ampliaba su versión beta privada para incluir AWS y lanzó un add-on para trabajar con Heroku, una plataforma para aplicaciones Ruby On Rails.

NimbusDB sigue ofreciendo una versión alfa a clientes seleccionados. Couchone y membase, dos no-relacionales NoSQL se fusionaron para ofrecer CouchBase para proporcionar ofertas integradas. En este mismo apartado de bases de datos NoSQL destacaría RedisToGo basada en Redis que en menos de un minuto nos crea un servidor listo para usar y MongoHQ para BBDD MongoDB.

Más información | Listado de DbasS
En Genbeta Dev | EngineYard ofrece un script de migración de Heroku a AppCloud