Cirrus.js 1.2 Beta – Http Server para Velneo v7

En esta nueva versión Cirrus.js evoluciona y ahora es capaz de servir web directamente entregando archivos HTML dinámicos, JavaScript y CSS, añadiendo para esto la capacidad de almacenar y editar estos archivos en tablas de la DB de v7 y sirviéndolos desde allí, para ello se realizaron los cambios en el código Js, las tablas correspondientes y la inclusión de ace editor.

Además para habilitar una mejora en el performance se incluyeron Cirrus workers, que básicamente levantan el mismo objeto TCP sobre varios puertos a fin de mejorar la concurrencia, permitiendo hacer un load balancing delante de Cirrus usando Apache, Nginx, Node.js, etc.

Para demostrar su uso, dentro con la open app de Cirrus.js se incluye la app de pedidos sobre la que se realizó una pequeña webApp con el fin de demostrar las funcionalidades de esta nueva versión, la cual se encuentra corriendo en pruebas.profitsoft.co.

Download Cirrus.js 1.2 Beta

Documentación (Wiki): https://github.com/heavyblade/cirrus/wiki

Screencast:

Notas de version 1.2:

Cirrus 1.2 se libera en modalidad beta para que sean probadas sus nuevas características las cuales incluyen:

  • Capacidad de servir HTML, Javascript y Css directamente sin web servers intermediarios.
  • Templates dinámicos usando Handlebars como template engine.
  • Inclusión de Ace editor, para realizar la edición de las vistas.
  • Cirrus workers para aumentar la capacidad de concurrencia.
  • Administración de layouts para ayudar en la re utilización de código.

v7 – Rsync + Ec2 + EBS backups en la nube para tus vServers

Después buscar alternativas y posibilidades para la estrategia de backup para la data y maquinas virtuales de vClouden al final encontré una solución simple, financieramente viable y rápida, la cual paso a detallar:

Donde almacenar ?

Aunque como mencione las maquinas EC2 no son precisamente baratas si las comparamos con otros servicios de VPS, lo cierto es que Amazon ofrece uno de las mejores y más económicas soluciones de almacenamiento disponibles (S3 y EBS), la primera para el almacenamiento de objetos y la segunda para el almacenamiento de volumenes para instancias de maquinas EC2, y particularmente importa la segunda por 2 razones:

1) precio:

  • $0.10 por cada GB/mes
  • $0.10 por 1 millón I/O requests

2) redundancia: cada unidad EBS es automáticamente replicada dentro de la zona de disponibilidad en la que se encuentre el datacenter, previniendo perdida de datos por problemas de hardware.

Que mecanismo ?

timemachine

Sigue leyendo

v7 – recogiendo data del visor HTML

Con el visor HTML de la v7 se pueden hacer infinidad de cosas en cuanto a visualización de data e inclusión de controles gráficos de diferentes tipos pero algunos casos el verdadero lió es lograr recoger la data que esos controles generan, como son editores, calendars, planificadores, UIs complejos, etc. así que utilizar este tipo de librerías genera mucho dinamismo pero tienen dos problemas que hay resolver para tomar la data generada o procesada por estas herramientas y guardarlas en la base de datos, ahora voy a detallar y solucionar estos 2 problemas:

1) Como recoger data generada dinámica mente y guardarla en la DB de V7:

El primer el problema es como lograr tomar la data que generan diferentes controles HTML y guardarla en nuestra DB, el asunto es que desde v7 tenemos acceso al código fuente del control HTML pero durante la ejecución del contenido html normalmente se genera más data y elementos que se adicionan al DOM y que no podemos leerlos desde v7 pues v7 solo ve el código fuente original, así que como recoger esta data que esta en memoria pues has sido generada dinámicamente ?

Pues lo primero que me percaté es que si bien la adición de elementos al DOM por medio de JQuery no aparece en el código fuente del documento, la inclusión de los mismo mediante Javascript puro y duro si lo hace, en este ejemplo estoy tomando el codigo html generado por ace editor y lo estoy guardando en un div especifico para luego recogerlo desde v7:

Contenedor:

<div id='html' style='display:none'></div>

Sigue leyendo

v7 – Enlaces a hermano y saldos acumulados

Uno de los problemas más comunes que nos podemos encontrar en las aplicaciones de gestión es el arrastre de saldos como ocurre en los inventarios basados en Kardex, libros mayores contables y flujos de caja, en este post voy a pasar a detallar metodología que uso en mis aplicaciones para solventar dicho problema.

Caso de estudio:

Para hacer la explicación más práctica abordemos el caso de una tabla de libro mayor contable que almacene por año, mes, tercero y cuenta  los saldos y movimientos:

saldos

Punteros y el indice HERMANO:

Quien haya trabajado con punteros a hermano en Velneo sabe que el éxito de la implementación depende de una clara definición del indice que se usara para indicar cuales registros son “hermanos” entre sí, en nuestro caso tenemos un indice llamado “HERMANO” que agrupa los indices por los que queremos realizar el arrastre => Cuenta (PUC), Tercero (Comercial), Año y Mes;  la importancia de este orden radica en que queremos que sean considerados como “hermanos” los registros que compartan la misma cuenta y tercero y que al recorrer dicho indice sea haga en orden por año y mes, esto ultimo para hacer más eficiente el código de actualización que veremos adelante. Sigue leyendo

vClouden – Sobre servicios IaaS y arquitectura

Un tiempo ha pasado ya desde la primera implementación de vClouden donde después de mirar y mirar proveedores de servidores me decante por AWS y su conjunto de servicios de almacenamiento y computación; y aunque fue una decisión tomada ello no implica que no siguiera revisando otros proveedores y modelos de virtualización por mero interés, lo que terminó cambiando mi forma de ver los recursos que necesita vClouden para funcionar y escalar.

Cambio de concepción: para vClouden no es necesario un cloud o IaaS complejo

Después de leer, re-leer, hacer pruebas y free trials, la conclusión es muy simple: el vServer es un solo servicio con una sola forma de conexión y por consiguiente no requiere de arquitecturas complejas para sus despliegue (load balancers, private networks, clusters, Queues, AutoScaling, Caching, etc.) así que proveedores como AWS, RackSpace, SendgGrid, Azure, etc. están sobrecalificados si solo vamos a usar sus recursos de computación, en otras palabras: no justifica usar un gran proveedor de IaaS como si fuese un proveedor de VPS, tal como puede verse en sus costos, las maquinas de AWS o RackSpace no son precisamente las más económicas si se les compara con servicios enfocados al vps únicamente como Linode.com (uno de los mas antiguos y respetados) y la razón no son las maquinas en si, es lo que esas maquinas pueden hacer dentro de su ecosistema y la gran cantidad de opciones en arquitectura que nos abren y por su puesto esas posibilidades se reflejan en sus precios, así que si estas usando uno de estos grandes proveedores de infraestructura como un mero VPS tal ves estas pagando demás por una cantidad de posibilidades que no estas usando.

Entonces que tipo de proveedor necesita vClouden ?

Dada su arquitectura vClouden solo requiere de unos puntos estratégicos, básicamente se requiere de un proveedor que:

  1. Tenga un API y pueda generar servers al vuelo.
  2. Que provea un SLA.
  3. Backups automáticos y snapshots de las maquinas creadas.

Se requiere un API dado que vClouden escala horizontalmente, es decir llena un servidor con vServers y automáticamente va añadiendo más para ir creciendo, esto con el fin de que el escalamiento sea automático y predecible, en cuanto al SLA al ofrecer servicios empresariales la estabilidad y disponibilidad es requisito SI o SI y los backups por obvias razones de control de riesgos además que son la base de la estrategia de escalamiento de vClouden.

digitavslinode

Con estos requerimientos y después de revisar varios proveedores quede entre 2 alternativas Linode o DigitalOcean, y despues de jugar con ambos servicios, revisar cuanto post y blog para hacerme una idea de sus reputaciones y problemas, me termine decantando por DigitalOcean dado sus costos, rapidísimo crecimiento en los últimos 2 años, su gran reputación por servicio al cliente y por su puesto su oferta de discos SSD, los cuales el vServer aprovecha en gran medida, simplemente vuelan !!!.

Impensada mejora en la arquitectura:

En ocasiones las mejores soluciones nacen sin pensarlas, como consecuencia de la evaluación de varios proveedores cloud y la definición de la estrategia de backups para la data de los vServers,  vClouden terminó con una arquitectura que es “Cloud  agnostic”, es decir podemos pasar de un cloud a otro sin muchas complicaciones, pues ahora todos los recursos de computo dentro del modelo son “descartables” y dadas las nuevas funcionalidades de LXC la creación de vms toma un par de segundos, por lo que es perfectamente viable pasar un servidor corriendo vClouden con 50 instancias en servidor de DigitalOcean a una maquina de Amazon EC2 en menos de 10 minutos, con lo que de ahora en adelante no estamos atados a ningún proveedor cloud en particular, siempre y cuando un proveedor tenga disponibles las 3 características arriba mencionadas será posible pasar todas las maquinas de vClouden.

Conclusión:

El resultado final de todo este proceso es el traslado a un servicio cloud que se enfoca en lo que vClouden necesita que son servidores puros, permitiendo costos mucho más bajos, discos muuuuuucho más rápidos, preservando las funcionalidades que de por si teníamos con Aws/EC2.

Liberado Cirrus.js 1.1.0 con importantes Mejoras

Hola, despues de recibir Feedback por parte de la comunidad y siguiendo con el roadmap de desarrollo para Cirrus.js hoy libero al version 1.1.0 con mejoras orientas a mejorar la estabilidad y el debug en tiempo de desarrollo, son 3 mejoras a saber:

1. Añadido un Logger de los request:

Ha sido añadido un Log donde podras ver cada request con su correspondiente response y poder asi inspeccionar que se le esta pidiendo a Cirrus.js y que esta entregando este, se puede acceder a el directamente desde el vDataclient o usar mediante herencia inversa un grid incluido en la caja de aplicación:

dataclient

uilogs

2. Entrega de Errores 500 y mensajes de error:

De ahora en adelante si existen errores en el código js que ejecuta Cirrus.js, el response sera de código 500 (Internal Server Error) y te entregara la información relevante del error en el response mismo, indicando el mensaje y la linea que produjo el error, lo cual será muy útil para realizar debugging y pruebas.

Vale aclarar que a hoy la v7 no es muy buena a la hora de dar el numero de linea de que esta produciendo el error si en un script se incluyen otros scripts js, por cuanto para calcular el número de linea del error parte desde los archivos incluidos hasta el script mismo como si todo terminara siendo un solo archivo js.

3. Mejoras en estabilidad y velocidad.

Se han realizado mejoras en código que parsea el resquest HTTP y como consecuencia del logger y el manejo de errores 500 es menos probable que código Js provoque una caída del vserver.

Download Cirrus.js Core

Download Tutor Cirrus.js

Un saludo,

de Cero a mobile con Cirrus.js y Velneo v7

mobile

Parte 1 – Integración de Cirrus.js y vBase:

En este screencast instalaremos Cirrus y vBase desde cero y realizaremos la integración hasta el punto donde el listado de usuarios de vBase es accible via web mediante JSON.

Si deseas ver el video en HD puedes ir a Youtube directamente.

Parte 2 – Aplicación Mobile:

Tomando como base el API del que ahora disponemos vamos a crear una pequeña aplicación mobile usando Trigger.IO desde donde listaremos los usuarios de vBase y generaremos un form para crear nuevos para finalmente correr el app en el Android Simulator.

Si deseas ver el video en HD puedes ir a youtube

La solicitud de inclusión en las OpenApps será enviada la próxima semana pero si no quieres esperar puedes descargar el .vin aqui

Espero la información les sea util y habra nuevos horizontes de desarrollo.

Cirrus.js + Nginx pure Performance

Dado que me han contactado varios miembros de la comunidad de V7 interesados en Cirrus.js me di a la tarea de realizar un load testing usando Blitz.io, digamos que quería saber hasta donde llega Cirrus.js.

Estos son los datos de las prueba:

Maquina: Amazon EC2 m1.medium con 3.7 Ram con una unidad de procesamiento y 2 cores virtuales, para disco use una EBS con IOPS a 400 (Input Output Per Second), corriendo sobre un Ubuntu Server 12.0.4 lts de 64 bits.

Velneo => version v7.7101

Prueba: => Básicamente atacar la ruta “/tareas” que esta definida en la open app de Cirrus.js que toma 10 registros de la tabla tareas y devuelve un JSON.

Resultados:

CONCLUSIÓN.

Como puede observarse básicamente lo que hace el load testing es atacar con usuarios concurrentes el path “/tareas” el objetivo es estresar el servidor para saber con que tanto puede, el resultado: el vServer muere a los 37 segundos mientras soporta 168 concurrentes repondiendoles a un rate de 118 visitas/segundo con lo que se pudieron lograr 3100 visitas en ese lapso de tiempo y pudiendo servir algo asi como 5.6 Millones de requests por día, después de lo cual comienza a dar timeouts y en consecuencia a disminuir el rate y los promedios.

MAS BUENAS NOTICIAS.

La primera:

Este load testing lo realice previo a unas optimizaciones que pienso implementar en el código de Cirrus.js, así que más velocidad esta por venir.

La segunda:

Esta es la mejor, estuve realizando pruebas y al parecer el vServer corre los puertos TCP cada uno en un Thread (hilo) diferente, lo que significa que al levantar sobre diferentes puertos el objeto TCP en el que corre Cirrus.js puedo multiplicar la concurrencia usando Nginx como un load balancer aprovechando todo el performance de su “Non Blocking I/O” y llevar hasta las nubes la capacidad de carga de Cirrus.js sin problemas de enganches.

Un saludo,

pdata: Cirrus.js ya soporta Cookies y sessiones, muy pronto un post documentando la funcionalidad.

Screencast Cirrus.js

En esta presentación veras el funcionamiento y caracteristicas de cirrus.js para darle accesso web a tus apps Velneo v7.

GitHub Repo

Tips:

- Para utilizar los archivos html de ejemplo de esta open App debes de descomprimir el archivo nginx.rar que está dentro del directorio cache de tu vClient.

- Para desarrollo web con v7 te recomiento usar cports para verificar el estado de tus puertos TCP y Fiddler para interceptar y hacer debug de todas las peticiones web-http logrando revisar el request y el response desde diferentes ángulos.

- En la fase de desarrollo es preferible levantar el servidor TCP desde el vClient, por cuanto si lo levantas desde el vServer y haces cambios en tu instancia cuando reinicies instancia el puerto queda abierto pero desligado del vServer y tienes que reiniciar el vserver.

Descarga: Puedes descargar la open app aqui, esta será enviada al catalogo oficial en los próximos días.

Saas en v7(II) – come on Cloud !!

Tal como indique en mi anterior entrada sobre Saas en v7(I), el modelo para despliegue que elegí es uno que permitiera “empaquetar” aplicaciones v7 + el vServer dentro de una Sandbox y que ese paquete constituyese una instalación y cada cliente puede obtener tantas instalaciones como desee dentro de su cuenta pagando exclusivamente por su uso.

Asi que primero lo primero, como se indico en el post de análisis este tipo de arquitectura requiere de un servicio cloud que permita abstraer los recursos de computo, a hoy el mercado de IaaS ofrece muchas potenciales soluciones y el primer filtro son aquellas IaaS que cuentan con una API completa que me permita manejar la creación de servidores, ips, almacenamiento, etc. asi que analize Amazon EC2, RackSpace con sus CloudServers y GoGrid, despúes de contrastar servicios, costes, seguridad y librerías disponibles, me decante por Amazon (una sorpresa escoger al lider mundial jejeje).

que nos ofrece amazon:

  1. Amazon ofrece un despliegue de infraestructura al rededor del mundo con multiples regiones y diferentes zonas de disponibilidad en esas regiones.
  2. Caracteristicas que crecen semana tras semana (solo hay que ver el NewsLetter).
  3. Elastic Compute (EC2), creación de servidores al vuelo pudiendo escoger entre diferentes tamaños y rendimientos usando plantillas (AMIs) para crear servidores pre-configurados.
  4. Elastic Block Storage (EBS), una razón super importante por rendimiento y seguridad, ya que las EBS se replican en las diferentes zonas de disponibilidad dentro de la region seleccionada ademas tener varios niveles de rendimiento en E/S.
  5. Costos bastante razonables.
  6. una API super completa ademas de la disponibilidad de una librearía Cloud para Ruby.
  7. Simple Storage System (S3), el sistema de almacenamiento cloud de Amazon.
  8. Elastics IPs, la posibilidad de mapear direcciones IP fijas a diferentes instancias EC2, importantisimo para realizar reconstrucciones que sean transparentes para los usuarios.

ok, ya tenemos los recurso de computo asi que, ¿ que arquitectura montamos ?, esta es la propuesta de vClouden:

En primera instancia esta la aplicación Web, esta desarrollada en Ruby on Rails y tiene la interfaz necesaria para administrar la solución Saas (crear Aplicaciones y añadir versiones, administrar los soportes, crear la documentación de tus apps y personalizar la interfaz de logeo), también el interfaz para los clientes finales quienes en ultimas utilizaran las soluciones v7 (login, soporte, documentación, instalaciones, etc.), esta webapp además se encarga de la administración de la infraestructura creando y configurando servidores, realizando las instalaciones que soliciten los clientes, backups diarios y demás tareas de adminsitrativas.

En segunda instancia esta Nimbus, esta es una aplicación pre-instalada en cada servidor que crea vClouden y que tiene la capacidad de crear SandBoxs e indicarle sus limites de rendimiento, en esta sandbox se instalara un vServer monopuesto y le instalara la aplicación v7 indicada, realizara las actualizaciones de versiones, desinstalaciones, mapeo de red para redirigir las comunicaciones hacia y desde las sandbox y realizar backup de data a pedido de los clientes.

Como puede observarse las maquinas EC2 tienes dos niveles, la maquina pura (la parte superior en amarillo) es solo la estructura de computo (CPU + Ram + FileSystem+ nimbus), la parte inferior contiene las Sandboxs y los datos de los vServers, esto es importante porque al estar estas dos estructuras separadas hace que los recursos de computo sean “desechables” y en el caso de un mealtdown o que una instancia este corriendo sobre hardware degradado simplemente se descontecta la parte de datos y se le conecta a una instancia nueva remapeando las ips para que el proceso sea transparente para el usuario.

Las SanBoxes

Son unidades aisladas en disco y rendimiento donde se instala un Velneo-vSever con tu aplicación, estas sandbox permiten otorgarle a cada aplicación lo que requiere para funcionar ademas de agregarle una capa de seguridad a todo el esquema añadiendo total aislamiento, cabe resalta que dentro de cada sandbox cada vserver es monitoreado para mantenerlo corriendo y vigilado por los perfiles de seguridad para que no haga mas de lo que debe hacer; este tipo de aislamiento además tiene una ventaja de futuro: tus apps podrán ser declaradas con dependencias (curl, libxml, Rmagick, etc), mismas que serán instaladas solo en las Sandbox de tus aplicaciones sin afectar a las demás.

y en cuanto seguridad ?

con esta arquitectura vClouden cuenta con 4 nivles de seguridad:

  1. El firewall y las propias medidas de seguridad de Amazon que no son pocas, aqui puedes ver un presentación muy completa sobre seguridad en AWS.
  2. El nivel de asilamiento que proveen las Sandbox, en lo que a tu aplicación y vServer respecta tiene un servidor solo para el solo, con un rendimiento fijo y su propio filesystem.
  3. Perfiles AppArmor para las Sanbox para evitar que acciones en las mismas intenten ejecutar comandos en el host como tal.
  4. Dentro de las sandbox, ademas de que el vServer no se corre como un usuario con privilegios de Root, cada vServer es monitoreado por un perfil AppArmor para asegurar a nivel de aplicación que no va a acceder a mas de lo que le corresponde.

y la Alta disponibilidad ?

Cada instancia de EC2 es monitoreada por Monit, este demonio revisa intervalos si los vServers estan arriba y de no estarlo se encarga de arrancarlo nuevamente, asi que si tu vserver cae por algun error en un proceso (que es lo mas común) será levantado automáticamente a los 10 segundos, y esto lo hará 5 veces consecutivas, a la sexta nos será notificado.