Las reglas clave para el desarrollo de apps nacidas en la nube

Las reglas clave para el desarrollo de apps nacidas en la nube

¿Estás desarrollando apps que viven en Internet? Aquí obtendrás 7 reglas que te ayudarán.

IBM Bluemix, la plataforma como servicio de IBM, brinda diferentes ventajas importantes para el desarrollo de una aplicación, entre las cuales se encuentran:

  1. Simplicidad y velocidad por medio de un enfoque en DevOps, lo que permite tener un despliegue continuo y en diferentes ambientes.
  2. Agilidad al permitir a la empresa enfocarse en lo realmente importante para el negocio y no en el mantenimiento de ambientes de desarrollo.
  3. Herramientas, al dar la libertad al desarrollador de escoger lo que ya conoce y que funciona para él, incluyendo diferentes editores de texto o IDEs como Eclipse, Sublime, Notepad++, etc, y diferentes lenguajes de desarrollo como PHP, Python, Ruby, Java, Node.js, etc.
  4. Control de código fuente por medio de la integración con diferentes sistemas de control de código (SCM – Source Control Management) como Git, GitHub y Jazz.
  5. Mercado de servicios, que permite el enriquecimiento rápido de las aplicaciones por medio de APIs y/o SDKs.

Si quieres más información de lo que es y las ventajas de Bluemix puedes verlo en el siguiente link.

Gracias a estas ventajas dadas por las plataformas como servicio (Bluemix), preparar (migrar) o desarrollar una aplicación para que funcione en una de estas plataformas en la la nube es ahora una tarea común, y la dificultad de esta tarea está totalmente relacionada a como fue o es desarrollada tu aplicación.

Por definición, una aplicación está lista para la nube si puede ser desplegada automáticamente en una Plataforma como Servicio (PaaS por sus siglas en Inglés) pública o privada, y además de esto, estar en capacidad de utilizar todas las funcionalidades y servicios brindados por esta plataforma. Del mismo modo, la aplicación no debe fallar por suposiciones hechas en el momento de desarrollo relacionadas a cómo funciona o no la capa PaaS. Es por esto, que muchos desarrolladores toman la decisión de cambiar sus aplicaciones tradicionales por aplicaciones totalmente nuevas y habilitadas para la nube, usando herramientas y runtimes también nuevos, como por ejemplo, el cambio de una base de datos relacional a una base de datos no relacional como Cloudant o mongodb.

Sin embargo, gracias a las ventajas que ya vimos de Bluemix, no tienes que ir al extremo de abandonar tu aplicación tradicional y las herramientas utilizadas; si tienes en cuenta las siguientes reglas básicas en el diseño de tu aplicación, puedes transformar fácilmente estas aplicaciones tradicionales a aplicaciones listas para la nube.

Estos mismos tips que veremos a continuación también se deben tener en cuenta para el desarrollo de nuevas aplicaciones nacidas precisamente en la nube.

  1. No desarrolles tu aplicación con una topología fija
    Como vimos en las ventajas, Bluemix tiene la capacidad de agregar y/o quitar servicios o instancias en cualquier momento, esto hace, que la estructura o topología de tu aplicación no sea fija, por ejemplo, una aplicación tradicional supone un ambiente de ejecución como un servidor con configuraciones fijas, o una base de datos con una determinada IP o hostname; en un ambiente en la nube no se pueden realizar estas suposiciones, en realidad no sabes si el nombre del servidor o la dirección IP es fija, por lo que tener estos datos “quemados” en el código, en el momento de desplegar tu aplicación puede traer problemas de estabilidad y seguridad más adelante.En el caso de Bluemix, debes usar las variables de entorno que se generan en el momento de crear un runtime y sus servicios, de tal forma que si decides cambiar las instancias o el tipo de servicio, estas variables tomaran la información generada en el mismo entorno, lo que asegura que tu conexión o configuración va a funcionar cuando realices el cambio en Bluemix.
  2. No asumas que sistema de archivos local es permanente
    Como el nodo de tu aplicación puede ser movido, borrado o retirado en cualquier momento, no puedes suponer que los archivos (imágenes, videos, documentos, etc) generados por la aplicación van a estar ahí para siempre. Supón que tu aplicación guarda las imágenes subidas en una carpeta pública en el sistema de archivos, en el caso en que el nodo de esta aplicación se caiga o sea movido, debes subir de nuevo tu aplicación y en este caso, pierdes toda la información almacenada en este sistema de archivo que no tengas en tu ambiente de desarrollo o en control de código fuente, es decir, pierdes toda la información que este en el cache de la aplicación en Bluemix.Para este caso, lo recomendado es almacenar toda la información generada por la aplicación en un repositorio externo a ella misma, es decir, en una base de datos independiente del estado, como por ejemplo una base de datos no relacional como Cloudant o Mongodb.
  3. No guardes el estado de las sesiones en la aplicación
    Dado que en el caso de la caída o modificación del nodo se pierde todo el cache, debes tener en cuenta que si tienes la información de las sesiones activas en este mismo cache, entonces por defecto, también pierdes, o en otras palabras cierras, la sesión de todas las personas que estén utilizando la aplicación.Para solucionar este problema aplica la misma regla del punto 2, esta información de sesiones la puedes almacenar en una base de datos no relacional como Cloudant, Mongodb o utilizar alguna que ya está diseñada para almacenar este tipo de información como Redisdb, todas soportadas por Bluemix.
  4. No guardes los Logs en el sistema de archivos
    Acá volvemos al mismo problema de las reglas 2 y 3, en caso de mover o reiniciar el nodo de tu aplicación, puedes perder toda la información generada por esta.Para no perder la valiosa información de los Logs de tu aplicación, puedes utilizar servicios, de código abierto, de colección y almacenamiento de Logs como Scrible o Apache Flume o algún servicio comercial como Splunk.Bluemix, gracias a que está basado en Cloud Foundry, cuenta con la herramienta Loggregator, la cual por defecto envía los logs a la línea de comando, en caso de querer guardar estos logs, te recomiendo enviarlos a una de las aplicaciones de terceros como Logentries, logstash, Papertrail o Splunk.
  5. No uses APIs de Infraestructura desde tu aplicación
    Este punto hace referencia a usar APIs o funcionalidades brindadas por el ambiente de ejecución, por ejemplo algún servicio dado por el Internet Information Server o el Websphere Application Server.Para esto, se recomienda usar APIs brindadas por terceros y también en la nube, por ejemplo, para enviar corres electrónicos, no utilizar un servidor SMTP dependiente de la misma infraestructura del servidor, sino utilizar un servicio de envío de correos como Sendgrid.
  6. No uses protocolos complicado o antiguos, mantelo simple!
    En muchos casos de aplicaciones de línea de negocio los desarrolladores acostumbraban usar protocolos de comunicación complejos, no estándar o desarrollados por ellos mismo, como por ejemplo envío de tramas TCP o controladores especiales para conectarse a una base de datos; todo esto puede ser difícil o imposible de configurar en la capa PaaS.En este caso, recomiendo usar protocolos simples, seguros y ya probados como servicios REST o incluso el un poco más antiguo SOAP, o en caso de algo más específico podrías considerar usar protocolos asíncronos como el MQ Light, en vez de intentar utilizar el HTTP para hacer algo para lo que no fue diseñado.
  7. No confíes en funcionalidades especificas del sistema operativo
    Volviendo al mismo problema de los puntos 5 y 6, no te puedes confiar de funcionalidades brindadas por el sistema operativo, como por ejemplo, en el caso de Linux o Unix utilizar “cron” para la programación de tareas o en el caso de Windows usar el Event Services.En el caso de Bluemix, cuentas con el servicio de Workload Scheduler, el cual te permite programar tareas simples o complejas en tu ambiente de ejecución para que se realicen automáticamente.

En conclusión, estas reglas sencillas te ayudaran a determinar la mejor forma de migrar o crear tu aplicación lista para la nube, es importante tener en cuenta que esto es solo una descripción básica de cada regla, en el momento de empezar a escribir el código de tu aplicación puede que encuentres algún problema con una nueva tecnología, por lo que te invito a dejar en los comentarios que regla consideras más importante y deseas que se lleve a un detalle más técnico, para crear algún tipo de tutorial o ejemplo que te ayude a realizar este cambio rápidamente.

 

Leave A Reply

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.