Hola, comienzo este hilo para compartir un email que he enviado como petición de un compañero del foro. Me voy a limitar a copiar/pegar, lo hago porque me he puesto ahí a escribir y he puesto muchas cosas que quizás más gente quiere comentar, corregirme o sugerir nuevas ideas. Recomendaría leer el post original pues es una respuesta al mismo, pero al ser otro tema distinto he preferido empezar otro hilo diferente.
Hola, te envío este mail a ráiz del hilo del foro de Velneo: http://goo.gl/zFWP8 Siento haber tardado tanto en contestar, vi tu mensaje pero no he tenido tiempo para contestarte bien hasta ahora.
Estoy utilizando dos servidores en la nube de Velneo. Uno es el que tengo asociado a mi usuario ebarbeito (vatp://v7cloud3.velneo.com:7288) que utilizo como vServer de desarrollo y otro asociado a otra dirección de correo que utilizo como vServer “en producción”. El mío, además de ser para desarrollo, lo utilizo para demos. Por eso incluso lo coloco como firma en mis posts del foro para que quien lo vea y sienta curiosidad acceda y con el usuario demo sin contraseña.
Supongo que hasta aquí ya te hacías una idea. A partir de aquí el resto tampoco es nada del otro mundo. Soy N1 y no he contratado nada (desgraciadamente no me lo puedo permitir pero me gustaría ser N2). El problema pues es cómo instalar tu desarrollo de un vServer a otro. vDevelop dispone de la funcionalidad “Importar componentes” en el menú Soluciones. Es la opción que utilizo para copiar una solución de un servidor a otro, en el manual de vDevelop tienes más detalles sobre ello http://goo.gl/Zr0eg
¿Y cuántas instancias utilizo? Tengo tres instancias para los dos servidores. En el vServer para producción hay una única instancia del programa: es la importante, donde van a parar datos reales. Luego tengo otras dos instancias en el vServer en desarrollo: una es la instancia fija llamada “(dev)” que es la que siempre utilizo para programar e ir probándolo todo. La otra la llamo “(prod)” y la utilizo para simular una actualización del programa a producción. Esta instancia sólo la creo cuando quiero hacer esa simulación porque no me interesa que al pulsar F5 en el vDevelop me la reinstancie. ¿Para qué hago esto? Imagina que tu programa en producción estaba en la versión 1.0.3, ahora estás con la versión 1.4.0 en desarrollo y has hecho algo en la base de datos que implica lanzar procesos para parchear o actualizar datos de una supuesta instalación con datos que tengas. Me he montado un sencillo mecanismo para ejecutar actualizaciones/parches de manera incremental que se ejecuta como parte del ON_INIT_SERVER de mi instancia de datos principal. Esto me permite probar la correcta ejecución de los parches/actualizaciones en mi instancia “(prod)” que emula la inminente actualización del programa en el servidor en producción (la instancia “(prod)” sería algo así como un despliegue en preproducción). Así me aseguro antes de actualizar en producción que todo va a funcionar bien.
Todo esto a lo mejor parece que está bien y que con N1 se pueden poner programas en real… yo no lo tengo nada claro:
-
Programar directamente sobre un vServer en la nube de Velneo es lento, se nota mucho sobretodo si estás acostumbrado a programar en local (en mi empresa somos N3 y ahí todo lo programamos/testeamos en local y en red local)
-
Tienes que ser muy cuidadoso y tener suerte de que tus instancias no manden el vServer al carajo. Todo lo que metas en los ON_INIT_SERVER se ejecutará al reinstanciar cada vez que pruebes algo pulsando F5 desde vDevelop. Estos procesos yo los uso mucho, por ejemplo tengo procesos de inicialización de tablas que se ejecutan al iniciar la instancia para verificar que ciertas tablas tengan al menos X registros creados. Los procesos de importación de datos también van por aquí. Si tienes muchos datos en formato CSV para importar, cuando se ejecutan tardan bastante y en mi caso me ha pasado que el vDevelop al importar el proyecto de un servidor a otro me ha mostrado mensajes de “Se ha perdido la conexión con el servidor” y cosas así. Luego todo ha ido bien, los datos están importados y todo parece estar correcto pero… a saber qué puede estar ocurriendo (tengo que mirar esto más en detalle, quiero comentárselo a Velneo a ver qué puede ser), y asusta.
-
Lo peor de todo: no tienes copias de seguridad. Y esto es el gran problema. La solución es desarrollar ese sistema de copias de seguridad / exportación de datos desde dentro. Si se quieren mover los datos de un vServer a otro en principio estás vendido, con un sistema así habría que ver si para muchos datos no colapsa el servidor. Esto es lo más delicado.
-
La sensación de inseguridad es grande. En el sentido de que “como ocurra algún problema” (con mis instancias, con la conexión que en mi caso programo en casa y no es muy buena, con la infraestructura AWS donde está alojado mi vServer, …) a ver cómo lo arreglas, si es que tiene arreglo y no terminas perdiendo todo el trabajo, y a ver cuánto tiempo te quedas parado (tal vez tengas que contactar con Velneo porque hay un problema con las instancias en tu vServer, y hasta que no te borren tu fichero de instancias no hay nada que hacer)
-
Es tedioso desplegar y redesplegar a producción utilizando la funcionalidad de importar proyectos. Si ya con vInstallBuilder+vAdmin es un poco coñazo reinstalar aplicaciones, haciéndolo así es bastante más.
No disponer del vServer y no puedes instalar aplicaciones en local, ni siquiera para ti mismo. …suena bastante triste ¿no? Y es una desventaja grande porque como a quien se lo instales sienta que su programa funciona lento te va a tocar utilizar muchas horas e ingenio para intentar conseguir que esa experiencia de usuario mejore sí o sí (porque no hay alternativa de vServer en local… repito muy triste) -
Sólo puedes tener un usuario conectado a la vez. Siendo N2 te permiten hasta 3 (y no sé si son ampliables siendo N2, tal vez sí). Esto es otra gran putada.
-
No puedes crear instaladores .vin. Siendo N2 sí. Y esto es otra gran putada y una gran carencia en N1. Para mí vInstallBuilder es tan básico como vAdmin, vClient o vDevelop.
No tienes vDataClient. Siendo N2 sí. Otra gran cagada. Es tan básico como vInstallBuilder, incluso mucho más. vDataClient debería estar para N1, con ello incluso más gente se acercaría a Velneo en mi opinión. -
Olvídate de los dos puntos anteriores y de otras opciones interanses como vModApache
-
…muchas desventajas más… la verdad que ser N1 es limitarte mucho a ti mismo y luego a tus “víctimas” (usuarios, clientes, lo que sea). Más valdría cambiar a otra tecnología más abierta (porque Velneo es muy cerrada) si se pretende uno tener clientela mientras te quedas en N1… es una locura, una chapuza de estrategia y perderás mucho tiempo y esfuerzo teniendo que ingeniártelas para hacer según qué cosas (mover proyectos, optimizar cuellos de botella en la aplicación que siendo ejecutado en una intranet ni te enterarías --aunque para mí esto es una ventaja que tiene la nube–, etc.)
La mejor idea es cambiar a N2 si uno decide dar un servicio profesional con Velneo. Sino podrás conseguir dar un servicio aparentemente profesional (como en mi caso, que es el experimento que estoy intentando hacer) PERO avisa a tu usuario/cliente/víctima de que (1) NO tendrá copias de seguridad (2) NO podrá disponer de su instancia en su ordenador/intranet (3) Sus datos estarán en un servidor que tu NO TIENES el control y por tanto él tampoco lo tiene de sus propios datos. No es un servicio profesional, por mucho que tu desarrollo sea lo más profesional que puedas realizar.
Un saludo
–
Enrique Barbeito García (@enriquebarbeito en twitter)
Mis demos en vatp://demo:@v7cloud3.velneo.com:7288