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

Seguir leyendo «v7 – Rsync + Ec2 + EBS backups en la nube para tus vServers»

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>

Seguir leyendo «v7 – recogiendo data del visor HTML»

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. Seguir leyendo «v7 – Enlaces a hermano y saldos acumulados»

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.

Deployment con vClouden

En vClouden las aplicaciones se almacenan como un cabecera que indica los datos básicos de la aplicación (Nombre, logo, cantidad de ram necesario y dependencias) y una serie de versiones que son las que realmente contienen el código fuente de las apps, en cada versión se incluye un archivo tar.gz que contiene la carpeta Velneo (Cajas + Datos server), la indicación de la version de V7 sobre la corre la app y el conscutivo de la versión. Cada versión podrá ser descargada de nuevo, borrada (si no tiene instalaciones asociadas) y por supuesto desplegada en producción.

aquí un video de como trabaja:

Algunas FAQ sobre el almacenamiento y despliegue de soluciones con vClouden:

¿Donde queda almacenado el codigo fuente de mi app ?

El código fuente de tu app queda almacenado dentro el servicio de almacenamiento de Amazon S3 en un repositorio privado el cual se encuentra protegido por todo el sistema de seguridad lógico, físico y de red de Amazon, si quieres hacerte una idea del nivel de seguridad de Amazon AWS esta presentación es mas que completa (http://www.youtube.com/watch?v=hEQIG_6B3VE&feature=plcp).

¿ Que sucede durante un Deployment ?

La secuencia de eventos despúes de que das click en «deploy» es: el servidor revisara todas las instalaciones que tus clientes hayan hecho de tu app y las agrupara por servidor, posteriormente creara una tarea para cada servidor indicandole que instalaciones debe actualizar y a que versión instalar, estas tareas se ejecutaran en 2do plano por un grupo de workers que se encargan de las tareas de despliegue en paralelo.

¿ y si me equivoco en el Deployment ?

Dado que Velneo V7 tiene la característica que al reiniciar instancias reconstruye el área de datos y hace las modificaciones que hayas hecho sobre la estructura de tablas, es posible que te equivoques y que consecuencia de esos cambios de estructura se pierden datos, por ello antes de cada deployment se hace un backup dentro de cada Sandbox (que dura 48 horas) para que puedas realizar un rollback inmediatamente sin perder nada.

¿ Porque debo indicar la cantidad de RAM que consume mi app ?

Porque esa cantidad de RAM será asignada a cada sandbox que correrá tu aplicación, de esta forma se aísla el consumo de memoria para que tu app no afecte el rendimiento de otras instalaciones que corren en el mismo servidor  y viceversa, ademas en función de ese consumo te serán facturadas tus instalaciones una vez establecida la estructura de tarifas de vClouden.

¿ Mi app tiene dependencias de librerías externas, puedo indicarlas ?

Si, aunque de momento se esta probando a nivel de código, vas a poder indicar las librería que necesitas (curl, libxml, Rmagick, etc) y serán instaladas únicamente en cada Sandbox donde se instale tu app.

¿ Que se viene en el tema de deployment ?

– Pues bien, por inquietudes y sugerencias de algunos Velneadores y dado que la arquitectura de vClouden lo permite, en el futuro podrás realizar instalaciones de forma manual desde la interfaz de administración, algo así como un mini sistema de hosting teniendo en tu cuenta un listado de Sandboxs de las que podrás disponer.

– A mediano plazo se esta contemplando el despliegue de deployments basandos en Git, para hacer mas efectivo el control de versiones.

– También se esta probando el poder ver desde el interfaz los logs de tu Velneo vServer y ayudarte así con el debug de posibles problemas que puedas llegar a tener.

bueno esto esto es todo, un saludo.

vServers con alta disponibilidad con Monit

Monit

Monit es una herramienta Linux para monitorizar diferentes componentes de un servidor tales como demonios, archivos, directorios, servicios de red ,etc. pero con una gran diferencia Monit puede tomar acciones por ejemplo cuando el servicio cae y ademas avisarte de lo acontecido, asi que vamos a utilizar esta herramienta para monitorizar un vserver, levantarlo en caso de caida y que nos avise por mail cuando suceda y vamos a hacerlo en un Ubuntu 12.04 LTS.

Primero lo primero installemos Monit:

sudo apt-get install monit

Ahora para monitorizar un proceso Monit necesita que indiquemos un pidfile, pero la instrucciones de arranque de los vServer no tiene la opción «–pidfile», asi como ejecutamos un Velneo vServer  pudiendo identificar su PID ?, tiempo atras tome unas lineas de codigo de un hilo del foro para crear un script de auto inicio y terminación de un vServer de tal forma que se inicie al igual que los servicios mas comunes para Linux y lo unico que hice fue añadir el codigo para asociarle un pidfile:

#/etc/init.d/vserver_init.sh
#!/bin/bash
 export PIDFILE=/ruta_donde_esta_vserver/vserver.pid
 case "$1" in
 start)
 /ruta_donde_esta_vserver/vServer.sh -s
 ps -e | grep vServer | cut -d" " -f 2 > ${PIDFILE}
 ;;
 stop)
 /ruta_donde_esta_vserver/vServer.sh -t
 rm ${PIDFILE}
 ;;
 restart)
 /ruta_donde_esta_vserver/vServer.sh -t
 rm ${PIDFILE}
 /ruta_donde_esta_vserver/vServer.sh -s
 ps -e | grep vServer | cut -d" " -f 2 > ${PIDFILE}
 ;;
 esac
 exit $?
<strong>

Ok ahora si tenemos un script que podemos usar para iniciar y parar nuestro vServer usando el comando:  «sudo ./vserver_init.sh start», básicamente lo que este script hace es iniciar el vserver y despues de iniciado lo busca en la lista de procesos activos y guarda su numero de proceso en el archivo .pid especificado en la ruta (PATH), yo personalmente escogí que el pidfile estuviera en la misma carpeta del vserver pero esto es opcional.

Procedamos a configurar Monit, para hacer esto vamos a ir a /etc/monit/monitrc lo abrimos con un editor (vim por ejemplo) y buscamos la siguientes lineas y las editamos:

set daemon 30 #revisa los servicios en intervalos de 30 segundos

#asignemos un servidor de mail via SMTP, intentalo con tu cuenta de Gmail

set mailserver smtp.gmail.com port 587

username «MYUSER» password «MYPASSWORD»

using tlsv1

set alert pedro_perez@mail.com #asignemos a quien enviar los correos

#Monitorizar tu vserver

check process vServer with pidfile /ruta_donde_esta_vserver/vserver.pid

start program = «/etc/init.d/vserver_init.sh start»

stop program = «/etc/init.d/vserver_init.sh stop»

if failed host 127.0.0.1 port 690 type tcp then alert

if 5 restarts within 5 cycles then timeout

Basicamente lo que hicimos fue decirle a monit: revisa mi vserver cada 30 segundos, estos son los comandos para inciarlo y detenerlo, en caso de caida levántalo y  notifícame a mi correo usando el servidor de correo de Gmail, si se cae mas 5 veces durante 2 minutos y medio terminalo.

no es Genial …

por supuesto Monit tiene mas para dar: un servidor web embebido para que puedas acceder via http y revisar el estado de los servicios, monitorizar carpetas (muy util para los vServers Express así obtendríamos notificaciones cuando se este acabando el espacio en disco), monitorizar archivos, comunicaciones TCP, etc.

pdta: en vClouden cada Sandbox tiene su propio Monit para cuidar el server.

SaaS en v7 (I) – El análisis previo

Desde que Velneo comenzó resaltar que la v7 estaba enfocado en el CloudComputing y que el el futuro de las apps de gestión era el SaaS,  muchos miembros de la comunidad comenzamos evaluar esta «nueva» modalidad y lo que aporta v7 para adentrarnos en esta nueva «ola», como resultado de esas consideraciones y muchas lecturas me embarque en el proyecto que hoy denomino vClouden, tratando de cerrar la brecha que hay entre v7 y las aplicaciones SaaS estandar(interfaz web, zona de clientes, soporte online, documentación, billing, etc.), de toda esa experiencia he logrado sacar algunas conclusiones que quisiera compartir y hoy comenzaré con el análisis previo.

 Que trae v7 a la mesa en el area del

Software como Servicio ?


No voy traer a colación las grandes ventajas de v7 desde el punto de vista del desarrollo de aplicaciones, mas bien voy a referirme a ella desde el punto de vista de arquitectura y lo que ello implica de cara a servir aplicaciones SaaS.

  • Posibilidad de conexión a travez de internet por defecto en la plataforma, ello implica que en cuanto a comunicación para un vServer son indiferentes las conexiones locales o las conexiones por internet, el simplemente te permite conectarte.
  • Cache de aplicaciones, después de la primera conexión en donde se «baja» la aplicación  solo se comunican datos entre la aplicación y el servidor de aplicaciones, además los inicios son instantáneos.
  • Cache de datos, los datos que le solicitamos a la base de datos, no tienen que enviarse en un solo paquete va llegando progresivamente como en un streamming de video.
  • Capacidad de manejar tablas locales en memoria para una mayor velocidad en ciertas operaciones.
  • El nuevo vUpdater, realmente útil para mantener a nuestros usuarios SaaS con la ultima versión tanto de nuestras apps como de la plataforma.

y todo esto que significa de cara a las aplicaciones ?, en pocas palabras: que tus cliente podrán disfrutar de un interfaz familiar y rápido, que solo transfiere datos y que siempre se mantendrá actualizado, teniendo la data de su negocio en la nube accesible desde cualquier lugar, además con la posibilidad de ser instalada como una app stand alone normalmente.

ok esto habla muy bien de las aplicaciónes como tal, pero y el resto del entorno Saas ?

Hacia una SaaS real con v7.

Antes de comenzar hay que imaginarse como debe ser una SaaS con v7 desde el punto de vista de lo que se le ofrece al cliente, aqui mi lista de deseos:

  • Interfaz web para registro clientes con una zona interna, la cual contendrá la instalación de aplicaciones, documentación, soporte, billing y datos de cuenta.
  • Darle al cliente la capacidad usar cualquiera de mis aplicaciones en cuantas instancias quiera por el tiempo que quiera.
  • Soporte Online deberá majearse tickets manteniendo la historia de la conversación ademas de notificaciones por mail.
  • Documentación online para las aplicaciones.
  • Darle al cliente la capacidad de tener backups de su propia data.

Antes de siquiera comenzar te enfrentas con el dilema de las instalaciones:

A la fecha solo se me han ocurrido tres formas de entregar un app v7 ne modalidad SaaS y aunque cualquiera de las 3 puede llegar a se valida dependiendo de las aplicaciones a servir, miremos los pro y los contra de cada una, tomando en consideración la lista de deseos:

1. Una instancia por cliente dentro de un solo vServer (Multitenancy): 

Tal vez la ideal en teoria y para la que supongo que Velneo apostaría de futuro pero de cara al Saas tiene varios peros importantes:

Pros:

  • Multytennacy real, actualizas tu aplicación automaticamente todos tus clientes tienen disponible la nueva versión, aunque te limitas a hacerlo cuando no haya nadie conectado, igual vale.
  • Durante un buen rato solo se administra un vServer y el escalado es mas a nivel de hardware.
  • Aíslas los datos de cada cliente en sus carpetas de datos.

Cons:

  • La falta de comandos que recibe por consola un vServer es muy limitada, así que de momento no hay forma de automatizar la creación de usuarios, grupos, instancias, carpetas, etc. automatización necesaria si queremos que el usuario puede tener tantas instancias de nuestra app como desee.
  • Aunque nos saltáramos el punto anterior el vAdmin no tiene facilidades de uso para manejar, buscar o filtrar instancias, por lo que personalmente no me imagino mirar un vAdmin donde hayan unas 100 o 200 instancias cada una con sus herencias.
  • Un tema particularmente importante es aislar el rendimiento de cada instancia, si dos usuarios pagan unos USD 20/ mes para usar tu app ambos debería tener el mismo rendimiento por su dinero pero que pasa si el usuario 1 tiene muchos mas usuarios conectados que el usuario 2 y los dos usan el mismo vServer?, por supuesto esta consideración en una escala mas macro.
  • Falta de información en cuanto a rendimiento, si, he escuchado que a los vservers los ha probado y les han dado mucha «caña» con millones de registros y conexiones, y les creo, pero a mi antes de confiarle buena parte de mi negocia a un vServer me gustaría conocer una publicación oficial que cuantifique el rendimiento de un vServer, cuantas contexiones, cuantos millones de registros, cuantas instancias, es decir … cuando un vServer comienza a deteriorar su rendimiento.
  • Costo: si o si tienes que comenzar tu Saas usando un vServer enterprise de ahi la importancia de conocer el rendimiento para conocer le costo beneficio de usuarios soportados vs costo del vServer enterprise + Hosting.
2. Una sola instancia que albergue a todos los clientes.
Esta es otra opción tambien factible, simplemente encargarnos nosotros mismos dentro de nuestra aplicación de la gestion de usuarios, grupos, permisos, etc.

Pros:

  • Solo gestionar una sola instancia y un solo vserver.
  • Administración de usuarios mas fácil y hasta una comunicación mas directa para crear nuevos clientes dentro de la app desde el interfaz web mediante vModApache o TCP.
  • Multitennacy para mantener a todos tus clientes con la ultima version de tu app.

Cons:

  • Mayor inversión en desarrollo al tener que crear todo el interfaz y la lógica de usuarios para el registro y logueo.
  • No hay un aislamiento de los datos de los diferentes clientes, todos estarían dentro de la misma db, aunque no es un requisito para algunos para mi es importante poderle decirle a mi cliente no solo que sus datos no los pueden ver otros, sino que físicamente están aislados entre si.
  • Dificultad para vender tu app en stand-alone dada la arquitectura necesario para que funcione como una Saas que no puede encajar dentro de una instalación local, sin mencionar que de cierta forma arriesgas tu know-how al tener una app que sirve para montar un Saas por ahí dispersa.
  • El mismo problema de la falta de información en rendimiento y costos que (1)

3. un vServer para cada cliente en la misma maquina usando algún mecanismo de Sandboxing.

Básicamente imitar lo que hace el cloud de Velneo a nivel de desarrollador pero en este caso a nivel de cliente.

Pros:

  • Estabilidad separada, si un vserver se cae por algun bug no afecta a las demás.
  • otra capa de aislamiento para los datos de cliente y mayor facilidad en el proceso de proporcionar backups cuando el cliente lo requiera.
  • Performace aislado para cliente (Depende del mecanismo de enjaulamiento)
  • Al tratarse el el vserver y la app como una unidad, se pueden realizar tantas instalaciones del mismo como se deseen.
  • No hay que preocuparse con que tanto puede dar un vserver.
  • Puede usarse el vserver monousuario para comenzar.
  • El escalamiento es lineal mas clientes, mas maquina y viceversa, claro usando algún servicio cloud.
  • El app sigue siendo el mismo asi que puedes vender tambien licencias stand-alone sin arriesgar el know-how de tus Saas.

Cons:

  • Administración de muchos vservers y tambien automatizar el escalamiento de los servidores en la nube donde se alojan los mismos.
  • Mucha mas Inversión en desarrollo para la automatización requerida
  • Lidiar con el licenciamiento de los vServers ya que vas a necesitar varios.

Bueno, dado los requerimientos me decante por la última opción, aunque requirió mucho mas I+D terminó siendo una solución mas abstracta y lo mejor de todo con la posibilidad de ser abierta para otros desarrolladores, continuare en el siguiente post contanto como pasé de este análisis previo a la implementación de vClouden.

Saas en v7(II) come on cloud

Saludos,

Que no es Velneo v7

Motivado por las recientes entradas en foro de velneo con respecto a la critica de diferentes carencias o caracterisitcas de la herramienta quisiera escribir unas lineas para darle aclarar un par de cosas a quines se acercan a la herramienta para que no compren algo pensado que es otra cosa:

Sobre la Herramienta:

Lo primero a aclarar Velneo NO ES un generador de codigo ni tampoco es un generador de interfaz, si bien es cierto que a primera vista parece un herramienta RAD, no lo es, por lo que su misión no es tomar n mil estándares y juntarlos de tal forma que  el desarrollo de aplicaciones de gestion sea mas llevadero,  entonces que nos vende Velneo ?, velneo se define a si mismo como «plataforma completa para desarrollo de aplicaciones empresariales», en esta frase hay que distinguir muy bien el «completa»: en este caso «completa» significa que usando unicamente Velneo puedes crear una aplicación empresarial entera sin depender de bases de datos externas, librerias externas, otros entornos de desarrollo, etc. Asi que en este sentido «completa» no significa que atienda todos los estandares habidos y por haber (UML, SQL, XML, etc), aun así se estan comenzando a implentar algunos que estarán disponibles a travez de QML y JavaScript.

Sobre la base de datos:

Bueno este es uno de los temas mas sencibles para quienes recien se acercan a la plataforma por 2 cosas: en primer lugar porque Velneo solo usa su base de datos propietaria y muchos quieren realizar sus desarrollos sobre otros motores o sobre bases de datos ya existentes, en segundo lugar porque la base de datos de Velneo tiene su propia forma de navegación a travez de los datos y su propia forma de realizar consultas, asi que para un programador proveniente de otra plataforma el NO SE USA SQL es un tabú para usar la plataforma y simplemente no concibe como trabajar sin esto.

1. Solo se usa base datos propietaria:

Aunque no recuerdo haber leido un post al respecto, Velneo no tiene y dudo mucho que algún dia tenga la intención de soportar otas bases de datos (la herramienta ya tiene 15 años y ni asomo del tema), esto obedece a que el gran valor de v7 es la integración que se consigue entre los objetos visuales (formularios, rejillas, acciones, etc) y la base de datos, basicamente por esto es que Velneo nos gusta a la mayoría, asi que yo veo dos posibles explicaciones para que esto siga así: la primera es que se requiere dominio sobre el fuente de la base de datos para realizar ese nivel de integración y las dos mas grandes bd orientadas al enterprise no son de código abierto (Oracle y SQL Server) asi que ni pensarlo, la segunda es que si se pudiera conseguir realizar el tipo de integración que provee velneo mediante mapeo ORM sería un esfuerzo gigantesco que la empresa no tiene con que afrontar (todos sabemos que el departamento de desarrollo de Velneo es pequeño), aunque son meras expeculaciones me inclino mas por la primera opción.

2. No se usa SQL:

Para algunos es simplemente inconcebible pero es la realidad, Velneo y su modelo de datos tienen una forma muy particular manejar el flujo y consulta de datos que simplifica en gran medida el manejo de la información en la aplicación y previene de errores de tipeo gracias a su editor de procesos asistido (No es perfecto pero para la gran mayoría de los casos es mas que suficiente); basicamente con este forma de manejar los datos velneo nos dice «esta es la forma en que nosotros creemos que se debe operarse la data de un motor de base de datos», ya esta en nuestras manos decidir si nos gusta ese angulo o no.

Asi que desde el punto de vista de la base de datos solicitar que se ataquen otros motores o que se puedan realizar consultas SQL, es cambiar la esencia misma de la herramienta no son un simple par de caracteristicas, auque me incluiria dentro de los que les gustaría que fuera posible editar sobre diferentes motores no me hago ilusiones por las razones expuestas.

Un saludo,