¿Programa en la nube?
Hola a tod@s.
Llevo observando de un tiempo a esta parte el tema de los programas "Saas" o "Cloud computing" o "programas en la nube" o como les quieran llamar. Hasta ahora no me ha preocupado demasiado ese tema porque no están todavía muy extendidos y depende para qué sectores, yo en particular, no lo veo una buena solución, pero ahora (en España) están incentivandolos mucho con ayudas, subvenciones, etc. y ya si que empieza a preocuparme. Mi pregunta es la siguiente: ¿hay alguna forma de un programa delphi "de escritorio" de toda la vida funcione en modo "cloud computing" o hay que hacer un programa nuevo?, ¿qué opinais sobre el tema?, ¿alguien tiene experiencia en este campo?. Saludos |
Si haces un programa de escritorio y lo pones dentro de un servidor con Terminal Service tendrás tu programa en la nube.
|
Cita:
Gracias y un saludo |
Cita:
Sin reescribir la aplicación cvreo que no hay otra opción. Si la aplicación puedes "pasarla" a FireMonkey sin grandes problemas, hay soluciones como esta, que permiten acceder a ella mediante un navegador usando HTML5, pero sinceramente tengo serias dudas sobre el rendimiento. Habría que evaluarlo. Échale un vistazo a las demos. Luego está el tema de las aplicaciones tipo Web (de las que hablamos en este foro), tipo uniGui, Raudus, ExtPascal,... Pero no son directas. Implican reescribir la aplicación (al menos la parte visual). No se me ocurren más... |
Para el tema de impresoras, existen solcuiones. Una es utilizar Citrix. Otra es utilizar Thinprint.
Ambas de pago... pero también lo son las licencias de Terminal Service. De todos modos, si es para una empresa a la que le montas el servidor, puedes montarle los drivers de las diferentes impresoras que tenga. |
Hola Newtron.
Ya llevas algún tiempo en el mundo del desarrollo y, como sabes, todas las "tendencias" y "modas" informáticas hay que tomarlas con pinzas. Con esto no pretendo desacreditar a la famosa computación en la nube, pero sí creo que hay que irse con calma viendo cada caso en particular. Primero es detectar, dentro de los usuarios actuales y potenciales de tu software, quiénes tienen o tendrán necesidad de acceder a la información de éste a través de Internet, mediante qué tipo de dispositivos, qué información en concreto deben poder ver y qué operaciones podrán realizar. Una vez que hayas analizado lo anterior, te será más fácil determinar la solución a aplicar en cada caso concreto. Me llaman a desayunar, buena suerte amigo. Al. |
Cita:
---- La "nube" es básicamente una forma de decir "Aplicaciones/Servicios n-tier interconectadas por protocolos de internet". Esto incluye no solo "paginas web" sino también las apps de dispositivos como iOS que de alguna manera utilizan un backend y/o otros servicios Saas (https://en.wikipedia.org/wiki/Software_as_a_service) y PAAS (https://en.wikipedia.org/wiki/Platform_as_a_service). Aunque se puede argumentar que una paginita en PHP es la "nube", en la practica este concepto se entiende no solo como el usar tecnologías web, sino la FORMA como eso se usa, a un nivel estratégico & de implementación, al igual que su enfoque. Algunos de los temas comunes en este tipo de apps: - ES una app. NO una pagina ni un sitio web. -Aunque la app *puede* ser implementada con tecnologías asociadas con pagina y/o sitios web. Un ejemplo: Pinterest, Facebook. En cambio, el sitio web de una empresa no entraria en el concepto. - Esta hecha para *escalar* bajo demanda. Si de pronto pasas de 10 a mil usuarios en *un dia* la app responde adecuadamente. - NO necesariamente es una app para consumidores. Puede ser que ofrezcas un API, un PAAS, un SAAS o un BAAS o una combinación de todo esto. Por ejemplo, si haces un servicio con un API REST que genera documentos en PDF en base a datos que envias por JSON, CVS o similar - Comúnmente, se construyen en parte o en totalidad sobre Amazon Web Services, Azure, Heroku y similares. Montarlo sobre el típico LAMP? Eso NO basta. Todo porque: - Lograr la escalabilidad, flexibilidad y resilencia de una app en la nube requiere destrezas y tecnologias complementarias (o que reemplazan en su totalidad) al típico: 1 motor sql, un lenguaje de scripting, una pagina o app de escritorio. Esto incluye: * Capacidad elastica de crear/destruir servidores, servicios de aplicaciones y similares bajo demanda (crear un servidor web y/o de base de datos y/o de apps y/o de dns y/o etc cuando se necesite) * (Posiblemente) Uso de librerías de cacheo (ie: Redis) * (Posiblemente) Uso de uno o mas engine NOSQL (ie: Redis, MongoDB, Cassandra) * (Posiblemente) Uso de uno o mas engines de SQL (ie: Postgres, MySql, ...) * Exponer un API. Esto es casi una marca definitoria de las apps en la nube. NO tiene que ser un api publica. Pero para orquestar todo la app 2-tier no es tan común, aunque sucede. * Consumir 1 o mas servicios de SAAS, PAAS, BAAS, APARTE DE LOS QUE TU HAGAS. Es muy difícil armar todo esto, así que esto es una característica definitoria. Ejemplos: parse.com, Apple Push Service, Google Maps API, Azure Mobile Services, Heroku PostgreSql, Amazon S3, Google App Engine, Amazon Elastic Cloud, New Relic, etc Lo mas popular para armar este tipo de soluciones es usar Python, Ruby, GO, Node, HTML5, iOS, Android, Redis, Mongo, Postgres, MySql, Cassandra, Couchdb, REST, JSON. Delphi nunca se ve en el radar mas allá de foros como este y de lo que cuenta embarcadero, lo que implica que es mas esforzado hacer parte del ecosistema (de hecho creo que muchos ni saben que tal cosa llamada delphi existe. Lo que no tiene que ver con su popularidad, porque he visto gente usando erlang, elixir, scala, y muchos otros lenguajes de nicho y tecnologias raras que están mucho mejor situados que delphi. No ayuda lo costoso de su entrada y uso). |
Cita:
Yo ahora mismo lo único que estoy es informándome de qué se mueve en ese mundo para poder decidir en un momento dado, si es necesario, embarcarnos en un desarrollo de ese tipo. Por cierto... casi todo lo que habla el amigo mamcx me suena a chino, es posible que ya esté mayor para estas cosas.... :D Gracias a todos y saludos |
Analizando un poco todo esto de "Programa en la nube" en forma práctica, lógica y simplista es muy fácil de explicar, comprender y de hacer:
¿Recordáis cuando salió windows y nuestros programas eran para MSDOS?, pues bien, ¿cómo se solucionaba el problema de una empresa que quería estar "a la última"?, fácil: Le ponías un servidor windows e instalabas el programa. En los PCs terminales se ponía un icono enlace al programa en el servidor windows. Desde los PCs terminales se ejecutaba el programa que estaba en el servidor windows. Voilà, programas en la nube. Ahora, en lugar de tener el servidor windows en la oficina, tenemos un servidor en cualquier lugar, por internet ("en la nube") y te conectas a él. Igual. Es el mismo funcionamiento, no cambia nada, esto es como las modas, que vuelven de nuevo pasado un tiempo. |
Cita:
La verdad es que ese sistema de trabajo, depende para qué empresas, tiene sus ventajas. Sobre todo para empresas con varias delegaciones y que necesiten tener la información accesible desde cualquier lado. Si, terminal server es una solución, pero una solución que tiene mucho trabajo de instalación y configuración de terminales, impresoras, etc. Esto es otra historia, desde cualquier dispositivo que tenga conexión a internet accedes y trabajas. |
Cita:
Aunque es cierto que se puede "maquillar" ciertas cosas de como se hacen antes y hacerlas llamar "nube", tal como apunta casimiro -y que dependiendo del contexto, en especial ante un cliente/colega ultradesinformado esperando que le digan los buzzwords del momento... puede ser necesario- no se debe ignorar que la nube tiene aspectos diferenciados del resto de apps/web tradicional. Si estamos hablando de tendencias o paradigmas: 1- Era MS: Apps locales, departamentales, mono/multi-usuario tipicamente 1-2 tier, donde ser parte del desktop (lease: Windows) es lo mas característico y cada app/dato es una isla. Aqui domina C++, VB. Las app son fundamentalmente "event driven", se comunican a duras penas en una intranet, y se puede 100% usar un solo lenguaje para resolver todas las necesidades de desarrollo. Aqui Delphi es muy fuerte. 2- Era internet: Genera dinamicamente paginas web con ligera funcionalidad de app e interactividad. Aqui domina PHP/LAMP. Las app son fundamentalmente "stateless + POST/GET". Siguen siendo islas. Es posible 100% hacer todo esto en UN SOLO servidor. Usar 1.000 servidores? Eso solo lo hace un grandote como Google. 3- Era nube: Apps altamente distribuidas en N-Servidores -que no necesariamente estan bajo tu control, sino contratados-, elasticas, que interoperan mediante APIs, que estan hechas en N-lenguajes & plataformas, que tienen interfaces en N-plataformas (html5, ios, desktop, etc). Son principalmente apps "stateless + POST/GET + PUSH/PULL + Event-Driven + Reactive + NOSQL/SQL + Caches + APIs + ...". Usar 1.000 servidores? Eso lo puede hacer CUALQUIERA con una tarjeta de credito, a costos infimos. Aproximadamente cuanto le costaria a newtron tener 1.000 servidores ya, en este instante? http://calculator.s3.amazonaws.com/index.html US 20 * 1 hora * Sin contar costos extras, solo las maquinas. Obvio esto se sube, pero hombre, US 20 * 1000 servidores? ----- Asi que lo que separa a las apps "nube" de las demas, y que esta implicito en el concepto de la palabra "nube" es la *escala* de la infraestructura y lo "nebuloso" de determinar todos los componentes, lo altamente distribuido y (potencialmente) intercambiable, el alcance global, no es para apps de intranet. Osea, es lo *mismo* que antes pero si lo "mismo" es un casa, la "nube" es una ciudad entera (ie: La nube se construye, obviamente, en base a todo la tecnologia y modelos anteriores). SIN EMBARGO hay aspectos que son exclusivos/nuevos que surgen exclusivamente para resolver problemas de estas soluciones. Por ejemplo, estas son tecnologias/servicios que tienen sentido en la nube: http://www.docker.com/ http://aws.amazon.com/es/products/?nc1=f_cc De estas, EC2 es lo unico medio-parecido al modelo de sitio web "normal". S3, Elastic Load Balancing, Elastic Block Store, DynamoDB, Redshift, ElastiCache, Route 53, Elastic MapReduce, Kinesis, Data Pipeline, etc... son el resultado de necesidades que surgen con el tipo de problemas que se enfrentan quienes hacen apps en la nube, y que antes eran practicamente innecesarios. |
Mamcx, si descendemos de la nube y pisamos tierra firme, no somos google, facebook y ni siquiera meneme.net
Estamos hablando de una gestión de ventas, básicamente, para una empresa pequeña (de 1 a 50 empleados) que quieran trabajar en la oficina, en casa o en la calle mediante un portátil o una tableta. Si recortamos todo ese maremagnum de siglas, nombres, paradigmas, lenguajes, sistemas, métodos, etc. que has nombrado (y que parece escrito para despistar :p), podemos reducirlo a algo mucho más básico: ¿Qué es lo más práctico, cómodo, ágil, económico y real para tener algo "similar" al antiguo servidor con un programa msdos al que se conectan desde otros pcs? Por cierto, "solamente 20 $ hora" son: 14400 $ mensuales -> 172800 $ anuales. Eso no es para una empresita pequeña. |
Cita:
Al igual que todo proyecto, hay que saber dimensionar las cosas. Con todo, es 100% factible usar un servicio que corre en la nube, aun si tu app es del tipo que describes. Por ejemplo, cuando usan google maps o geolocalizacion, aun siendo la app monousuario, Google maps esta en la nube, esto es, un efecto colateral es que ahora se puede acceder a muchos recursos que antes eran imposibles para un equipo pequeño. Por ejemplo, para la app que estoy haciendo, que es tal cual como la describes, utilizo varios servicios en la nube, no por seguir una moda, sino porque es practico hacerlo. |
Lo que quiero decir es que con tantos nombres, tecnicismos, etc. lo que haces es confundir a la gente, en lugar de ayudar a aclarar las cosas ;)
|
Cita:
Cita:
P.D. Que bueno que existe la computación en la nube, y que bueno que resulte tan útil en algunos casos. Puede que Newtron encuentre algún valor en ella para sus proyectos. :) ^\||/ |
Club Delphi,
Cita:
Esto resume el concepto de Cloud Computing: Cita:
Cita:
Cita:
Cita:
Cita:
Nelson. |
Cita:
Cita:
Cita:
|
Cita:
---- Lo que pasa con los tecnicismos es que trato de dar terminos y servicios concretos que definen este tema. Es como decir "Que es todo eso de la OO?" y no hablar de herencia, polimorfismo, etc.. Aunque es bueno simplificar el asunto a una frase o 2, sin dar una idea de la dimension... se puede entender mal la cosa y pensar que hay que ir en otra direccion. |
Pues....¿sabéis?... cada vez estoy más liado con el asunto.
Mi inquietud es saber si a una "mierdaempresa" como la mía le sería factible abordar de alguna manera el desarrollo de una aplicación de ese tipo o está fuera de mi alcance. |
Cita:
Volviendo a la pregunta... Cita:
Como ya hemos visto, el concepto de "programación en la nube" incluye muuuuuuuchos conceptos y no todo el mundo los necesita todos (más bien al contrario). Podríamos concretar el escenario que necesitas, y así ver posibles soluciones (o modificaciones mínimas) para que "ese mismo programa de escritorio" (condición única que has puesto) pueda funcionar en ese nuevo escenario. => Lo digo por que no es la primera empresa ni la última (incluyendo la mía) que se va a encontrar con situaciones similares. (1) Proyecto grande (escritorio) (2) Sin presupuesto ni personal para realizarlo "de nuevo" desde cero. (3) Con necesidad de cambio de escenario. |
Según lo leido anteriormente lo que voi a decir no tiene nada que ver con la nube. Tengo una antigua aplicación desarrollada en delphi 2.0 y sobre la que aún tengo que ir haciendo modificaciones de vez en cuando y con la que tuve que adaptarme a los nuevos tiempos. Al final está montada en un servidor citrix. El usuario final solo sabe que tiene que descargar el plugin de citrix para su navegador web, escribir la url que le paso, poner su usuario y contraseña y utilizar la aplicación de escritorio que desee de las que tiene publicadas.
Es cierto que básicamente no es distinto de conectarse mediante la red local al servidor de aplicaciones de la oficina. Pero la sensación que da al usuario final sin demasiados conocimientos se parece bastante. Aún con los quebraderos de cabeza lógicos el proceso no supuso el esfuerzo que habría supuesto realizar la aplicación de nuevo. |
Primero de todo, como siempre, es coger papel y lápiz y escribir lo que se quiere conseguir, las distintas opciones que podrían ser factibles y luego ver los pros y contras de cada una para escoger a la más idónea para tus necesidades.
(1) Lo más simple es poder usar los programas actuales que tienes (delphi) en windows corriendo sobre un servidor linux. De esa manera puedes aprovechar para tener varios windows al mismo tiempo en un mismo servidor, ahorrando costes de hardware. Siendo fácil añadir más servidores con más clones windows con los programas delphi. Los clientes, he aquí el problema, tendrían que ejecutar algo similar a "terminal server", algún otro programa VNC o incluso hace años existía un "terminal server" libre y gratis que funcionaba muy bien, era más ágil que el "original" y no tenía problema con las impresoras. El problema es que le perdí la pista hará unos ocho o diez años, pero supongo que existirá algo similar o mejor. Esta opción obliga a los usuarios usar pcs, portátiles o tabletas con windows. (2) Si se quiere que el usuario pueda usar "lo que quiera", ya sea windows, android o iOS, entonces no vale, principalmente por la impresora, aunque hay posibilidades distintas, como por ejemplo: que los listados no se envien directamente a una impresora, sino a un documento PDF, ese documento PDF es enviado al usuario e independientemente del sistema que tenga (windows, android, etc.) se imprime porque es un pdf. (O sea, no enviar documento a impresora, sino a PDF y enviar el PDF al usuario. El usuario lo imprime como quiera y con lo que quiera y pueda) Las otras opciones pasan por hacer nuevos programas, así que de momento creo que no es lo que estás buscando. Creo que la opción (2) puede ser bastante factible, habría que investigar un poco, pero así sin darle muchas vueltas a la cabeza, puede ser factible. |
je, je... 3 respuestas en menos de 10 minutos.
La opción citrix tiene varios inconvenientes, pero el principal es el precio, creo que newtron, aunque no lo ha especificado (realmente no ha especificado nada :p ), está pensando en el menor gasto posible añadido para él y sus clientes, sería un sobrecoste más, que tal y como están las cosas... :( La opción terminal server tiene el mismo inconveniente, otro gasto añadido, aunque también tiene la obligatoriedad de usar windows, cosa que es peor. Al menos con citrix tiene un abanico mayor de posibilidades. Yo me decantaría (previo análisis, investigación, estudio, etc. etc. etc.) por crear una máquina virtualbox, por ejemplo, básica de winXP, eliminando todo lo innecesario, dejándola en la mínima expresión posible, y la tendría como "plantilla" para todas las nuevas que se vayan necesitando. Esas máquinas virtuales winXP correrían sobre un servidor linux con una buena cantidad de memoria ram (para ejecutar la mayor cantidad posible de esos clones winXP). Por cpu no hay que preocuparse hoy en día. Habría que calcular qué memoria usa la gestión actual de newtron, pero casi seguro que con 1 giga va más que sobrado, así que con un equipo ubuntu server, debian o similar con, por ejemplo 8 gigas de ram y una cpu de 6 u 8 cores, puedes ejecutar tranquilamente y totalmente sobrado, al menos 6 máquinas virtuales (dejando 2 gigas para linux), de sobra para la mayoría de pequeñas empresas. Con 16 gigas de ram ya abarcaría 14 máquinas virtuales. Y si hace falta se añade otro servidor y... hasta el infinito :p Evidentemente, todos estos son números a lo bruto, habría que probar, investigar, afinar, etc. |
Cita:
|
Cita:
Y esto aplica tanto a la hora de desarrollar como a la hora de usar. Como puse en http://clubdelphi.com/foros/showthread.php?t=86291 la cantidad de recursos disponibles ahora son tantos, que el problema es saber que escoger! ---- Retomando la pregunta " Que hay que hacer para, usando Delphi (y lo que sea) usar la nube?". A nivel tecnico? Casi siempre es cuestion de inscribirse/contratar algun servicio de los mencionados y hacer llamadas a API mediante HTTP y/o usar algun SDK. Para cosas pequeñas los costos son 0 o muy bajos. Por ejemplo, mis sitios web los monto en http://heroku.com/ y no me cuesta nada. Tambien puedes obtener 1 año gratis con Amazon y con Azure, junto a http://www.microsoft.com/bizspark/default.aspx que te dan 3 años de licencias de MS, Azure y todo al final pagas como US 200 o algo asi. Basicamente, todo se reduce a pensar que quieres o necesitas, y mirar si ya hay un servicio que lo resuelve. Te pongo un ejemplo. Digamos que quieres mandar mensajes de texto a cualquier celular, pero no quieres (como toda persona sana) negociar con cada operador de cada pais. Entonces usas https://www.twilio.com/. Lees los docs en https://www.twilio.com/docs/api. miras si hay un SDK en tu lenguaje y sino es pan comido, usas llamadas REST y resuelves el problema en menos de 2 dias (lo que generalmente toma hacer un cliente REST). Asi que si tienes algun tema *concreto* en mente, es solo que preguntes, seguro que tengo por ahi un link a algo que te ayude ;) En ultimas? Esto no es tan dificil... de hecho es *trivial* para cosas pequeñas. Solo se puede poner interesante si tu app empieza a escalar de alguna manera. |
Cuando oí hablar por primera vez de la "Computación en la Nube" pensé:
Cita:
|
Ñuño Martínez,
Cita:
Cita:
Cita:
1- En Cloud Computing todos los recursos disponibles son ofrecidos como servicios (IaaS, PaaS, SaaS), los cuales pueden hacer o no uso de computación distribuida para su implementación. 2- En Computación Distribuida el objetivo es la unificación coordinada de recursos de computación distribuidos en una red para la ejecución y resolución de problemas de forma conjunta, no incluye en su concepción la idea de servicios ni virtualización. 3- Cloud Computing es una clase de Grid Computing (Una forma de computación distribuida) y su principal tecnología es la virtualización. En Resumen: A pesar de ser conceptos que tienen puntos en común en lo que a distribución de recursos se refiere, el concepto de Cloud Computing es más amplio e incluye más tecnologías, la idea principal que subyace en el modelo de Cloud Computing es : Servicios a un bajo costo de forma masiva, escalable y resiliente. Espero sea útil :) Nelson. |
¿Resiliente? ¿eso qué es? :confused:
|
Casimiro,
Cita:
Revisa esta información: Cita:
Espero sea útil :) Nelson. |
¡Ah!, elástico o flexible.
|
Hola a todos de nuevo.
Antes de nada pediros disculpas por este paréntesis de una semanita. He estado dedicado a cuatro cosas fundamentales (se me ocurre alguna más pero este es un foro público y puede haber menores :D): Playa, piscina, comer y beber, y por supuesto sin ningún dispositivo electrónico a mano. Creo que el amigo Neftali ha resumido perfectamente mi problema, que parece que es un problema común. La idea es que el cliente pulse en un iconito o llame a una página web, que se le pregunte un nombre de usuario y una clave y que acceda a su programa. Como se apuntaba por ahí una posible solución sería montar el programa en un servidor y acceder mediante terminal server pero no lo veo una solución elegante para uso genérico por el problema de las impresoras, la idea es que el cliente esté donde esté y tenga la impresora que tenga pueda usar el programa sin mayores complicaciones. Yo tengo bastantes instalaciones de terminal server y van muy bien pero son clientes que están controlados por nosotros en hardware y software y procuramos dejarlo todo instalado y configurado. Se habla de Citrix pero eso no sé ni lo que es, ¿alguien me lo explica como si yo fuera un niño?. :D Saludos |
Si no necesitas la capacidad de distribución ultra-masiva del html/browser, no le veo un problema a hacer exactamente para escritorio tal cual como se hace en mobiles: Una app nativa que "habla" mediante protocolos de internet a un servidor (de BD y/o de app).
Si se quisiera hacer como una pagina web, se puede generar PDF. O se puede hacer un mini-cliente que se instala en la maquina (como un plugin) que tenga la capacidad embeida de responder a llamadas http/websocket y que desde js se invoke para el control de impresoras y demas. |
newtron,
Cita:
Básicamente es una tecnología de virtualización de servidores, estaciones de trabajo y aplicaciones para su distribución en forma de servicios. Revisa esta información: Cita:
Nelson. |
Cita:
Cita:
|
Ni la nube ni internet dicta que los clientes tienen que ser obligadamente html. El exito de las apps en móviles muestra eso. Y si el cuento es automatizar las actualizaciones de las apps, pues las mismas muestran como se hace (y hacer que una app de escritorio se mantenga al dia es trivial estos dias).
|
Bueno, entonces una posible solución sería descargar la aplicación en modo local y mantener la base de datos en la nube, ¿no?.
Tengo otra pregunta, ¿las aplicaciones que se usan en cualquier dispositivo o sistema operativo qué son, html o hay alguna otra forma? |
Muchas gracias por la aclaración, Nelson. Por lo que veo, no estaba completamente en lo correcto al decir que son lo mismo, pero muy desacertado no andaba ya que, si no entendí mal, cloud computing es un subconjunto dentro de la computación distribuida.
¿Ahora sí? |
Ñuño Martínez,
Cita:
Cloud Computing es un Super Conjunto que incluye a la Computación Distribuida y otras tecnologías , la Computación Distribuida no incluye en su concepción la idea de servicios ni virtualización que son la base del concepto de Cloud Computing. Espero sea útil :) Nelson. |
Cita:
|
Cita:
|
La franja horaria es GMT +2. Ahora son las 02:38:20. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi