Mis saludos en este principio de semana lluvioso y tristón, acompañado de esa llovizna ligera y unas nubes bastante grises y plomizas. ¿Qué tal, compañeros?
Cualquier fecha es buena para retomar la actividad. 🙂
Así pues, me reencuentro con vosotros con esta entrada que abre el año 2014, tras un periodo de algunos meses en los que ha predominado ciertamente la ausencia, aunque para ser justos, producida ésta por motivos de trabajo. Quiero decir con eso que para mi sigue siendo importante este blog y lo que pueda aportar a la Comunidad, desde la humildad con la que intento que siga adelante.
Pero es verdad que lo que mas se ha resentido en estos dos o tres últimos meses, ha sido el blog, ya que, el poco tiempo libre, en la medida que me ha sido posible, lo he dedicado a seguir el contacto de la Comunidad a través de la actividad desplegada en el grupo de Facebook, que conocemos como Delphi Solidario, y que gracias a la implicación de todos sigue siendo día a día un motor de noticias y un indicativo del pulso de una parte de nuestra Comunidad. En el otro lado seguimos teniendo los pilares que suponen los dos grandes grupos que en buena medida la representan, Club Delphi y Delphi Access, y que acogen a un buen porcentaje de compañeros que activamente siguen apoyando y compartiendo su tiempo, bien a través de las publicaciones en blogs, bien a través de los foros y comentarios públicos en las entradas. Si os estáis acercando por primera vez a Delphi a través de esta entrada, (a veces se dan esas casualidades), no dejéis de visitar y explorar todos los recursos que encierran estas dos grandes comunidades de amigos, y sin duda de grandes profesionales.
Pero vamos a lo que vamos… al grano…
A mediados de Enero, justo antes de que publicara mi buen amigo German Estévez, del blog /*Prog*/Delphi-Neftalí/*finProg*/, la primera de las entradas de la serie: (1/5) Aplicación de acceso a datos (Introducción), compartía con él varios correos sobre lo que realmente es el meollo de la serie que luego ha ido publicando. Vaya por delante mis felicitaciones a Germán por la gran calidad de sus artículos, que injustamente. estamos tan acostumbrados, que no los valoramos suficientemente, por cuanto suponen esa programación mas cercana a nuestra realidad y vivencias y siempre útil, algo que sin duda se agradece. Así que mi recomendación, a quienes se acercan a este blog, que no dejen de visitar sus aportaciones en esa y otras series anteriores. ¡Felicidades Germán!.
La discusión era fácil de resumir desde mi punto de vista: desgraciadamente existen contextos donde no siempre podemos fácilmente desplegar el numeroso abanico de altas y grandes capacidades que nos da la herramienta y nos enfrentamos a tomar decisiones en base a estas limitaciones que realmente no atañen a la herramienta en si, sino al contexto real que vivimos. Ese es un poco el quid de la cuestión.
Podéis leer el ejemplo que pone Germán en esa primera entrada introductoria, donde establece un hipotético proyecto en base a unas condiciones previas que nos limitan, creo yo, como un arquetipo de esa inquietud que puede manifestarse de mil formas. En las empresas que conozco, empresas pequeñas o medianas, con pocos recursos en algunos casos, es relativamente sencillo montar un esquema cliente-servidor o incluso un despliegue de múltiples capas apoyado en DataSnap, dentro del área de red de la empresa, por supuesto, ¡considerando este caso como un caso reducido y aislado en ese Universo!. Fuera del caso singular, las cosas adquieren muchas ópticas y las decisiones no son hechas de forma sistemática sino que requieren de nuestra habilidad para sacar el máximo partido y explotar al máximo los recursos que disponemos.
Tenemos una herramienta de propósito general ciertamente con puntos fuertes en cuanto a drivers de conexión a datos, que se combinan con múltiples tecnologías y ahora inclusive en distintas plataformas , lo cual nos da un abanico muy grande de posibilidades. Y el hecho de que los sistemas windows estén tan extendidos frente a otros sistemas es otro plus a favor en ese contexto que nos favorece (al menos en lo que atañe a los servidores datasnap)
Si tuviera que resumirlo en una sola palabra, casi seguro que elegiría la palabra «limones», algo muy valenciano, de mi tierra…
Ese dicho de que la vida nos da limones, no Naranjas como muchos quisiéramos de antemano, y aprendemos a sacar el jugo para regalarnos una limonada muy fresca o como dicen algunos, para combinar la sal y el tequila.
🙂
En la serie que Germán está compartiendo con nosotros, la solución de urgencia es ese WebService en php que aprovecha así la posibilidad de exponer desde un servidor linux compartido, algo que es fácilmente accesible y disponible por las Empresas. Luego, el consumo de los datos desde la parte cliente, aprovecha toda la potencia que nos da Delphi: iOS, Android, MacOSX, Windows de Escritorio, etc…
Imagen de la Serie en el Blog Delphi-Neftali
Pues bien… Nuestra discusión giraba en torno a todo esto, filosofando en una tarde cualquiera, pero quizás mi curiosidad me llevaba a buscar otras posibilidades, que no había probado…
Y si mi servidor de datasnap…
Esta era la pregunta que en ese momento me hacia ¿Y si mi servidor de DataSnap estuviera en la Nube?. Fue precisamente una de las preguntas que cruzamos y que yo me había hecho tiempo atrás, y que en ese momento, sinceramente, no tenía respuesta porque no había dedicado tiempo a experimentar. Tampoco sabia si existía algún tipo de impedimento técnico, fuera de que sea mas o menos oneroso o mas o menos inseguro. Así que mi despedida se cerraba con el comentario a German en el sentido de que intentaría complementar su serie con esta posible experiencia. Y bueno… realmente eso ha sido lo que ha motivado estás lineas.
Me hice un esquema gráfico que visualizara la idea que quería experimentar
Bueno… ¡visto así parecía algo factible!. Un servicio de base de datos alojado en cualquier servidor compartido de Internet, exponiendo públicamente una instancia de mysql o similares para linux. También podría ser un servidor compartido windows, con Sql Server, (que concretamente es el caso del servidor que aloja el sitio de este blog y que nos valió en su día para probar el ejemplo del Taller de Delphi Básico). O incluso, llegado el caso nuestro propio servidor en la plataforma adecuada, desde alguna ip fija, en la empresa o cualquier otro lugar de confianza con la base de datos elegida. Y por otro lado, una instancia de servidor virtualizado en la nube, como la solución que nos ofrece Amazon Web Services (AWS), desde el servicio de EC2, exponiendo nuestro servicio de DataSnap. Y en la parte exterior, consumiendo los datos, los clientes nativos de las distintas plataformas que son posibles generar desde nuestra herramienta. Con total independencia de que esos datos expuestos desde la nube fueran entregados desde un webservice o una canalización TCP/iP.
Si nos vamos a lo concreto, para este experimento, la receta mas o menos siguió estos pasos:
1- Abrir una cuenta en AWS y tras ese registro inicial cumplimentar todos los requisitos. Esta cuenta nos da acceso a un abanico amplio de servicios en la nube, entre los que se encuentra el que hace referencia a la virtualización de servidores.
2- Activar una licencia de Windows Server 2012 en el servicio de EC2 (Amazon Elastic Compute Cloud o Amazon EC2).
3- Subir a ese servidor en ejecución, el servidor de DataSnap que usamos en el Taller de Delphi Básico celebrado en la semana del 26 de Octubre de 2012, compilado ahora con Delphi XE5, y
¡voila! El cliente de DataSnap, ejecutado desde mi equipo, encontraba el servicio que exponía el servidor de DataSnap desde la nube, accediendo a los datos de un servidor compartido windows (el de mi blog) que alojaba una instancia de SQL Server, justo lo que se mostraba en el esquema que compartía al inicio.
El que ese servidor de bbdd estuviera fuera de esa Nube, como era el caso, o que se incluyera dentro de ese u otro servidor en Amazon EC2, que podía incluir el motor de SQL Server, era un poco lo de menos. Como reza el apartado que explica el servicio, el peso fuerte de AWS es la posibilidad de dotar a nuestros proyectos de recursos escalables y personalizados a la medida de nuestras necesidades.
Esta es, por ejemplo una vista de los servicios que se pueden contratar desde nuestro perfil en AWS:
El servicio de EC2: Unas pinceladas
La idea que uno puede tener de sus servicios antes de conocerlos puede ser un tanto vaga ya que si os fijáis en la imagen superior, AWS recoge tanto las áreas de computación y redes, almacenamiento de datos, analítica, desarrollo y aplicaciones de servicio. He contado a bote pronto unos 27 servicios distintos, gestionados a través de un interfaz web y una consola de gestión de servicios que nos permitirán administrarlos de una forma relativamente sencilla, sobretodo si tenemos en cuenta la complejidad que encierran.
La documentación es amplia. En muchos caso está traducida a nuestro idioma. Adentrarnos en este mundo puede suponer la lectura de muchas paginas para tener una buena idea, a pesar de que el contacto con la Nube se facilita en buena medida. De hecho, en mi opinión resulta impagable la capa gratuita que dispone AWS para que el usuario se inicie y pueda poner en marcha sus pruebas de desarrollo con el menor coste posible (coste cero si la usamos de forma adecuada). Al registrarse, los nuevos clientes de AWS reciben cada mes y durante un año los siguientes servicios de EC2:
- 750 horas de uso para la ejecución de instancias Linux/Unix Micro en EC2
- 750 horas de uso para la ejecución de microinstancias Microsoft Windows Server en EC2
- 750 horas de Elastic Load Balancing más 15 GB de procesamiento de datos
- 30 GB de almacenamiento del volumen estándar de Amazon EBS más 2 millones de E/S y 1 GB de almacenamiento de instantáneas
- 15 GB de ancho de banda saliente en todos los servicios de AWS
- 1 GB de transferencia de datos regional
EC2 básicamente nos ofrece la posibilidad de virtualizar servidores en la Nube. Toma ventaja desde el momento en el que disponemos de un control absoluto de las instancias creadas y se integra dentro de un esquema de pago por uso, con un catalogo amplio de opciones, inclusive contamos con la posibilidad de adquirir instancias de software preconfiguradas y listas para su uso desde la tienda de Amazon (AWS Marketplace): https://aws.amazon.com/marketplace
Creo que no está de mas conocer las posibilidades que nos pueden aportar, por lo que os invito a que leáis esta documentación que os introduce en el servicio y sus posibilidades:
https://aws.amazon.com/es/ec2/
Por supuesto otro punto fuerte es la escalabilidad, que sea adaptable a nuestras necesidades pudiendo ajustar y personalizarlo con el software que necesitemos.
Opciones de instancias de Amazon EC2 en la capa gratuita
Para que veáis que el abanico disponible es amplio, he generado una pequeña tabla que resume y extrae los datos de los sistemas operativos disponibles en la capa gratuita. Con todos ellos vamos a poder hacer pruebas, casi todos disponibles tanto en 32 bits como en 64.
| FREE TIER | |||
| Amazon Linux | 32 | 64 | |
| The Amazon Linux AMI is an EBS-backed, PV-GRUB image. It includes Linux 3.4, AWS tools, and repository access to multiple versions of MySQL, PostgreSQL, Python, Ruby, and Tomcat. | |||
| Red Hat | 32 | 64 | |
| Red Hat Enterprise Linux version 6.4, EBS-boot. | |||
| SUSE Linux | 32 | 64 | |
| SUSE Linux Enterprise Server 11 Service Pack 3 basic install, EBS boot with Amazon EC2 AMI Tools preinstalled; Apache 2.2, MySQL 5.5, PHP 5.3, and Ruby 1.8.7 available | |||
| Ubuntu | 32 | 64 | |
| Ubuntu Server 12.04.3 LTS with support available from Canonical | |||
| Ubuntu | 32 | 64 | |
| Ubuntu Server 13.10, with support available from Canonical (http://www.ubuntu.com/cloud/services). | |||
| Windows | 64 | ||
| Microsoft Windows 2012 Standard edition with 64-bit architecture. | |||
| Windows | 64 | ||
| Microsoft Windows 2008 R2 SP1 Datacenter edition and 64-bit architecture. [Multi-Lang] | |||
| Windows | 32 | 64 | |
| Microsoft Windows 2008 R1 SP2 Datacenter edition. [English] | |||
A modo de conclusión
Esta entrada nos sirve como introducción, presentando el experimento o idea, y en la segunda parte, que preveo la pueda tener preparada al fin de esta misma semana, comentaríamos con un pequeño vídeo o imágenes los pasos y algunos problemas que solucioné sobre la marcha, de forma que vosotros mismos podáis hacer alguna prueba.
Disponer de un servidor virtualizado en la Nube puede tener algunas ventajas frente a la opción de exponer públicamente el servicio de DataSnap desde un servidor propio, con salida a través de algún router y adsl al uso. Por un lado me parece evidente que se interpone el acceso a la dirección real de ubicación de nuestro servicio de bbdd, algo que parece recomendable desde el sentido común y desde el punto de vista de la seguridad, puesto que podemos establecer reglas de confianza en la comunicación de la capa de datos y la capa del servicio. Por otro lado, el servicio es escalable y personalizable. Podríamos tener múltiples servidores llegado el caso y crear estrategias de balanceo de carga en función de los picos que el propio negocio genera. Son muchos detalles que hacen interesante explorar las ventajas de la Nube, que lógicamente no voy a descubriros yo.
Y para finalizar, a algunos quizás les de una alegría al comentar que me propongo volver a realizar en fechas cercanas nuevamente el Taller que hicimos sobre DataSnap, al que hacia referencia a lo largo de la entrada. Un taller gratuito y con un numero pequeño de plazas y que sigue en esa linea de ayudar a quienes dan sus primeros pasos. No anticipo nada mas 😀
Buen camino a todos.
Delphi Básico 
Interesante explicación de AWS. Merece la pena ‘jugar’ un poco por Amazon a ver que tal. Actualmente mis servidores de datos (DS / REST) los tengo en un servidor propio bajo Strato, pero creo que la política va a cambiar y subirán los precios, así que merece la pena estudiarlo.
Un buen aporte de información el artículo. Gracias.
Me gustaMe gusta
¡¡Grande Salvador!!
Felicidades. Fantástica entrada en cuanto al detalle y a la amplitud de la explicación. Me parece un fantástico complemento a la publicada en mi blog.
En el apéndice final (que espero publicar) la analizaré con más detalle.
Esperando la segunda parte… 😉
Un saludo.
Me gustaMe gusta
Antes de nada felicidades, no sólo por al entrada sino por todo lo que estáis haciendo por la comunidad.
Me gustaría saber si el DS del ejemplo es via TCP o REST.
Yo ya tengo soluciones con DS en servidores virtualizados utilizando TCP.
Me di de alta en BizSpark de microsoft donde también te dan horas para consumir en servicios Azure.
Aún no he entrado en profundidad porque el día a día nos consume a todo pero mi idea es intentar migrar alguno de mis servidores actuales hacia Azure.
Uno de los puntos que veo críticos es el tema de Balanceo de carga y la elasticidad tanto de AWS como de Azure, para que quadren con nuestros servidores DS, sobretodo si trabajas comunicándote via TCP.
Es tarde y estoy un poco espeso 😉 a ver si abro algún hilo en DelphiSolidario y discutimos de que arquitectura deberían tener nuestras aplicaciones DS para podernos aprovechar al máximo de la elasticidad y balanceo de servicios como AWS y Azure.
Saludos,
Me gustaMe gusta
Hola Rafa:
Gracias por tu comentario.
Respecto a la pregunta, las pruebas las hice vía TCP, que era el ejemplo por decirlo de alguna forma, mas completo que tenia a mano y que pudiera subir a AWS. Supongo que una vez abierto el camino, caerán mas experimentos de todo tipo, incluyendo a rest. Sería bueno en general para todos, para toda la Comunidad, que nos apoyáramos mutuamente compartiendo esas experiencias y se discutiera de los problemas reales de estos despliegues. Mi inquietud por ejemplo respecto a AWS podría estar ahora en valorar coste real de activarlo frente a soluciones mas tradicionales. El papel da mucho juego y sobre el papel todo funciona.
Ayer por ejemplo, casualmente sin duda, me visitó en mi trabajo un gestor de telefonía, concretamente de Movistar y uno de los puntos que salieron fueron las soluciones que proveen de Servicio Cloud y Cloud Avanzado en unos datacenters propios. Tengo previsto en las próximas semanas volver a celebrar una reunión para obtener detalles mas concretos. Básicamente, son servicios «similares» al que comentaba pero el pago es mensual, de aproximadamente unos 100 euros en la versión mínima.
¿Alguien puede dar detalles orientativos del coste «real» de un despliegue de EC2 o Azure?
Saludos
Me gustaMe gusta
En lo del coste ‘real’ de los servidores EC2 , les he formulado una consulta directa, con una duda que me surgió, nuestro servidor DS esta funcionando continuamente, sirva o no datos en ese momento, pero por lo que me pareció entender, al ‘consumir’ procesador y memoria, nos cargarían por hora un dinerito, si tenemos varios servidores para varios clientes, puede ser necesario hacer calculos y yo me lié con la calculadora que incorpora para hacer calculos de costes y al final lo dejé hasta que me resolvieran la duda.
Actualmente, uso un servidor cloud de Strato bajo windows, el cual me permite instalar windows 2008 y 2012, con o sin parallels para la gestión de los mismos. Lo adquirí con 4 Gb de ram, y 200 Gb de Disco duro (concretamente el producto Windows L, que actualmente ya ha bajado de prestaciones a 120 Gb y 2 Gb), solamente con la intención de probar a subir los servidores a un servidor y probar que tal funcionaban, el coste fue bastante bajo, 6 meses gratuitos (actualmente la oferta está al 50%) y un coste mensual de 9.90 + Iva (actualmente 14.90 al mes), no es muy barato, pero el acceso por TS es bastante bueno y rápido, los servidores DS/REST que tengo, tirando de SQLSERVER van bastante bien, aparte de estar siempre el servidor con otras cosas como varios programas de atlassian como JIRA, CRUCIBLE y repositorios SVN.
Coincido con Rafa en la idea de ‘estudiar’ cuales son los medios de que podemos disponer para crear servidores de datos remotos al menor coste posible y con las mayores prestaciones.
Me gustaMe gusta
muy buen articulo.!!!
Me gustaMe gusta