cloud

Utilizo Digital Ocean desde hace años para mis proyectos personales y mis webs basadas en Drupal. Estas son las razones por las que seguiré utilizando este servicio por mucho tiempo.

Digital Ocean fue inicialmente una plataforma para la gestión de máquinas virtuales (VPS) con almacenamiento SSD, cuando todavía los discos duros de estado sólido eran caros en el mundo cloud en relación a otros servicios de hosting. Además, tenían una concepción diferente con respecto a otros servicios similares, como Azure, AWS o Rackspace: extraordinaria sencillez en la admistración y orientado completamente a desarrolladores de software.

Con el tiempo, han ido añadiendo más datacenters y han ido pasando de ofrecer un servicio de plataforma como servicios (Paas) a infraestructura como servicio (Iaas), con balanceadores de carga, redes privadas, almacenamiento, gestión de DNS, etc., pero manteniendo la simplicidad como principio. Su panel de control (o dashboard), es asombrosamente sencillo y te da la información rápida y precisa del estado de los recursos que tienes contratados y del coste actual acumulado.

Un máquina virtual se denomina en Digital Space un droplet, que, a diferencia de una VPS tradicional, incluye monitorización de seguridad y de comportamiento por el mismo coste. Puedes crear un nuevo droplet en segundos partiendo de una instalación base de alguna distribución de Linux o alguna imagen preconfigurada con los paquetes software más populares (stacks LAMP, LEMP o MEAN, Docker, MySql, Wordpress, etc.), además de crear un droplet a partir de un snapshot de una de tus propias máquinas ya configuradas.

A continuación, recibes un correo con la contraseña del usuario root y la dirección IP de la máquina recién creada, y poco más, ya tienes acceso a tu nuevo servidor.

Aunque los precios para máquinas virtuales caen cada vez más, en Digital Ocean tienes un droplet con una distribución de Linux de 1Gb de RAM, 1 CPU, 25Gb de almacenamiento y 1Tb de transferencia por 5 dólares al mes..., suficiente para probar cosas o publicar aplicaciones sin demasiadas exigencias (dos de mis webs, ésta y www.gblanes.com, están en una máquina con esas características con un rendimiento más que suficiente). Por el momento, las imágenes bases son siempre distribuciones de Linux.

Digamos que Digital Ocean está evolucionando poco a poco a suministrar servidores virtuales a proveer verdaderamente de servicios cloud.

Como cualquier infraestructura hardware, las actividades de mantenimiento o actualización la informan con tiempo suficiente para que estés al tanto de que tus droplets pueden verse afectados (normalmente esto ocurre poco y la falta de servicio dura minutos). Algunas de mis máquinas virtuales llevan dos años funcionando ininterrumpidamente.

Por otra parte, una característica que me gusta especialmente de Digital Ocean es su enorme sección de tutoriales con una calidad extraordinaria, los utilizo frecuentemente para resolver algunos problemas o recordar cómo se hacía esto o aquello. Imagino que deben tener una política de calidad o algo similar, ya que me llama la atención que verdaderamente se trata de documentación cuidada, bien editada y clara.

Otro punto que me gusta mucho de Digital Ocean es que se incluye con el mismo coste un servicio de monitorización y de alertas para tus droplets (recientemente me avisaron que una de mis máquinas virtuales, al no tener actualizado Drupal a la última versión, estaba realizando un consumo de ancho de banda excesivo. Después descubrí aprovechando una vulnerabilidad de la versión no actualizada de Drupal, me habían instalado un minador de bitcoins..., ejem...).

Al igual que otros servicios similares, disponen de una API con la que se pueden programar la creación de recursos y gestionar su uso.

Si estás buscando un proveedor de máquinas virtuales para algún proyecto, Digital Ocean es una opción que te recomiendo.

Uno de los aspectos que siempre me han gustado más sobre el desarrollo de software ha sido optimizar y mejorar el rendimiento, sobre todo de aquellas partes de un proyecto que pertenecen más al core y de lo que depende todo lo demás.

Con el desarrollo masivo de aplicaciones web y teniendo en cuenta que la economía se está moviendo a lo digital, trabajar en el buen rendimiento de un sistema puede suponer una gran ventaja competitiva y generar mejores resultados económicos.

Por alguna razón siempre he visto cómo todo lo relacionado con el perfomance sólo nos ha preocupado como desarrolladores cuando esto suponía un error en el sistema, de modo que si algo funcionaba (aun con una latencia de algunos segundillos) pues a casi nadie le importaba. Ahora no, ahora hay que arañar hasta el último milisegundo y por supuesto ganamos la batalla si la percepción del usuario final es la de que algo va a golpe de clic. También he visto cómo se ha intentado solucionar problemas graves de rendimiento con más hardware...

El rendimiento de un sistema no consiste sólo en que funcione con la velocidad adecuada, sino también en que el usuario que lo usa perciba que responde ágilmente y de manera instantánea.

Lo que defiendo en este post, sobre todo en desarrollo web, es que trabajar con el rendimiento en mente se debe hacer desde el principio hasta el final del proyecto.

No hace mucho leí que un usuario percibe algo como instantáneo si obtiene una respuesta en menos de 100ms, entre 100 y 300ms percibe un ligero retraso, entre los 300ms y el segundo ya nota un retraso apreciable, después de un segundo se produce lo que se llama un cambio mental de contexto (mental context switch, o sea, que empieza a pensar en otra cosa) y a partir de los diez segundos (!!#***xxxx)  ha abandonado lo que intentaba hacer... En estos dos últimos casos las posibilidades de que abandone la web son muy altas. Una web lenta echa a los visitantes como moscas en una fábrica de insecticida.

Esto tiene un impacto brutal en webs en donde una tasa de rebote alta significa menos usuarios y por tanto menos posibilidades de materializar algún tipo de resultado en el site (en forma de nuevas inscripciones, ventas, descargas, etc.). Por tanto, trabajar en mejorar el rendimiento no es que sea algo secundario, sino que sin él todo lo demás que hagamos seguramente no tenga tan buen resultado como esperábamos.

Tradicionalmente los equipos de desarrollo se han preocupado del rendimiento de lo que hace al final del proyecto, cuando ya se da casi por cerrado y cuando posiblemente apenas se tenga ya tiempo parar mejorarlo y todo el esfuerzo pendiente se deba dedicar a detectar y corregir errores de validación. Esto es un error en el que yo he caído mil y una veces..., no obstante, como se suele decir, nada mejor que señalar los errores ajenos cuando uno mismo ya los ha cometido previamente, de modo que más que considerarme presuntuosamente experto, tendría que decir que la experiencia me ha dado muchas (y dolorosas) lecciones.

Desde el primer momento en que se comienzan a generar assets en el proyecto, del tipo que sea, hay que comenzar a trabajar desde el punto de vista de su rendimiento; en otras palabras, tenemos que integrar en el día a día el mejorar esos assets como una parte más del trabajo, sobre todo si el éxito o fracaso del proyecto dependen de la buena o mala percepción de los usuarios en cuanto a usabilidad y tiempos de respuesta del sistema. Me pregunto, ¿pero es que existe algún sistema software que se pueda permitir que un usuario esté varios segundos esperando para hacer cualquier cosa trivial? Claro, los hay, y muchos, me temo, y seguramente esos productos estén en la línea roja con posibilidad de ser sustituidos por la competencia.

El trabajar desde el principio en mejorar el rendimiento no es inocuo ya que de alguna manera, escribir con la optimización en mente implica:

• Crear estructuras de código optimizadas en donde ahorrar tan sólo unos cuantos ciclos de CPU es importante. Es difícil a veces encontrar el equilibro para seguir manteniendo código legible sin ofuscarlo al optimizarlo.
• Trabajar con el rendimiento en mente impacta también en el diseño del sistema: no sirve de nada plantear una arquitectura de la información fantástica si detrás no está respaldada con saltos ágiles y rápidos cuando un usuario navega por una web.

El mejorar el rendimiento implica a todos lo que trabajan en el proyecto: desarrolladores, diseñadores, arquitectos de información, etc.

El rendimiento no es sólo que un trozo de código funcione lo más rápido posible, es un concepto poliédrico, con muchas caras, sobre todo en una aplicación web donde hay muchísimos elementos involucrados:

• Conseguir un buen performance depende de la infraestructura software que usemos (servidores HTTP intermedios, SSL, etc.)
• Hay que establecer una buena estrategia de caché para los distintos elementos de la web.
• Hay que analizar si es conveniente o no usar CDNs.
• Hay que validar y optimizar (minificando y contatenando) los ficheros CSS y js. Sí, los estilos se pueden optimizar para que el navegador tarde menos en procesarlos y renderizar los resultados.
• Si se hace un uso intensivo de imágenes, estas deberían estar optimizadas y habría que ver en qué casos se podría emplear la técnica de uso de sprites.
• No hablemos ya si plateamos una web con estrategias de RWD o RESS, ahí se complica un poco más las optimizaciones según el dispositivo del usuario.
• Hay que tener mucho cuidado de las librerías externas o de terceros a usar y detectar cuales de ellas pueden constituir un SPOF y dejar K.O. el site.
• Lo que entendamos por buen o mal rendimiento depende del tipo de proyecto.

No podemos dejar todo ese trabajo de auditoría y análisis de rendimiento (de calidad, en definitiva) para el final, sino que hay integrar esas tareas en el workflow habitual de trabajo o en los procesos de entregas o integración continuas si se tienen establecidas.

Lo más importante de todo (y quizá lo más difícil): el trabajo sobre el rendimiento de algún aspecto concreto se debe poder medir de manera automática para poder ver el progreso o retroceso a medida que avanza el proyecto.

Estamos comenzando un nuevo proyecto para el mercado eléctrico, en esta ocasión 100% web (con un backend que extrae información de un enorme repositorio de información alojada en cloud); estamos integrando en el primer prototipo todas las métricas de rendimiento que nos permita analizarlas a medida que el proyecto avance en los próximos meses además de integrar en el flujo de trabajo habitual la generación automática de todos los assets optimizados. Espero así que este trabajo, que al principio parece extra, consiga que los usuarios finales del site perciban un sistema ágil y por tanto consigamos generar una percepción positiva del mismo.

Me gusta Etsy, no sólo porque implementa en la realidad una economía colaborativa hacia la que, en mi opinión, todo debería converger, también porque cuenta con un equipo de desarrollo supermotivado que además publican sus insights. En su blog hablan mucho de rendimiento web.

Quizá por el entorno laboral en el que me muevo o por el tipo de productos software específico en el que trabajo, veo desde hace unos años una tendencia imparable; sí, ya sé, ni la nube es algo nuevo y tampoco es una moda que todo el mundo olvidará dentro de unos años. Lo que quiero decir es que más allá de titulares y opciones disponibles para desarrollar software, comienzo a ver en el día a día un interés real sobre todo lo relacionado con soluciones en cloud entre los clientes y las empresas que les proveen de soluciones software.

La razón de esto es sencilla: costes más reducidos y plataformas de servicios en la nube muy maduras que comienzan a ser bien conocidas por las empresas que desarrollan software.

Tenemos actualmente clientes que utilizan nuestros productos en modo Saas (software as a service) desplegado en la plataforma de computación en la nube de Microsoft, Azure, y la verdad, la experiencia desde hace dos años es extraordinaria.

Realmente estamos viviendo un cambio de paradigma en el desarrollo de productos software, muy real y muy a tener en cuenta entre aquellos que ahora mismo se están formando para esta profesión, aunque lo que quiero destacar aquí es que contrariamente a lo que algunos creen, programar para la nube no tiene en absoluto nada que ver con programar una solución para su despliegue en equipos locales en los que tú mismo o alguien de tu empresa administra.

Programar para la nube es además poder usar una serie de servicios que sólo están disponibles en esa infraesctructura y que afectan a la naturaleza de tu aplicación.

Es verdad que una aplicación para escritorio o con una interfaz de usuario web la puedes desplegar en una infraesctructura en la nube (con Azure, Amazon AWS, Rackspace, etc.); sin embargo la nube ofrece muchísimos más servicios para el desarrollo de aplicaciones. Utilizar los servicios que todos esos proveedores te ofrecen no es sólo tener un medio sencillo para hostear tu aplicación, es muchísimo más.

Si decides comenzar un nuevo sistema desde cero teniendo en cuenta algunos de esos servicios, la anatomía de tu aplicación será muy distinta que si usaras otro tipo de infraestructura.

Azure es desde luego el servicio que mejor conozco, aunque he hecho pruebas para algún proyecto prototipo con Amazon AWS y Rackspace con una percepción muy positiva.

Hablar de la nube es también hablar de escalabilidad a un coste razonable e infraestructura para almacenar datos de manera masiva. La explosión de todo lo relacionado con el big data y el Internet de las Cosas (IoT) no serían posible si no existieran servicios de computación en la nube a unos precios realmente asumibles para muchas compañías. Es más, la tendencia es que los precios vayan bajando cada vez más.

En Azure, por ejemplo, me gusta en especial todos sus servicios de almacenamiento masivos; según las necesidades de tu aplicación, puedes optar por una base de datos relacional administrada (Sql Azure) con distintos sabores de rendimiento, un servicio de almacenamiento de tablas no relacional para almacenamiento masivo de información sencilla con particionado automático (table storage) y también almacenamiento masivo para ficheros (para disponer de tu propio CDN, etc.). Esto es sólo la punta del iceberg y un sencillo ejemplo, aunque lo importante es que todos esos servicios están accesibles a través de una API que puede ser accedida por distintas tecnologías y lenguajes (C#, Node.js, php, etc.).

Ya no se trata sólo de programar bien, saber plantear las mejores arquitecturas eficientes, simples y mantenibles para una solución en concreto; además hay que conocer todas esas posibilidades de despliegue hacia las que se está moviendo el mercado. El éxito de un producto software no está sólo en su desarrollo, también en encontrar una solución de despliegue eficiente, mantenible y al menor coste.

Con un mercado que puede ser global, lejos quedan los tiempos en los que hacías un portal web hosteado en un servidor dedicado sin pensar demasiado en qué pasaría si el número de usuarios creciera diariamente un 5%...

Lo interesante de todo esto no es que los servicios en la nube están disponibles sino qué cosas seremos capaces de hacer con esos servicios económicamente asequibles para crear nuevos tipos de soluciones.

Este paradigma de desarrollo tiene un gran impacto no sólo en lo que nos afecta a los desarrolladores de software, responsables de proyectos o aquellos que como yo, tenemos la responsabilidad de elegir las mejores tecnologías para lo que desarrollamos; también afecta a la economía real al escalar procesos y crear nuevos mercados donde antes no los había.

En mi opinión, y por poner un ejemplo, todas las plataformas, soluciones y propuestas relacionadas con la economía colaborativa tienen mucho que ver con poder ofrecer sistemas muy escalables (con miles o millones de usuarios) a un coste que hace pocos años sólo se lo podían permitir grandes multinacionales.

La economía colaborativa no es una entelequia para gente alternativa, es una realidad creciente y más que apreciable en nuestro día a día y si no que se lo digan a Albert Cañigueral, cuyo magnífico libro recomiendo.