Cloud Foundry y Micro Cloud Foundry para desarrolladores Spring

Las últimas semanas he estado colaborando en un interesante proyecto, una prueba de concepto que incluía entre otras cosas el uso la infraestructura de Cloud Foundry para proyectos con Spring en el backend -parte de la que se ha encargado un servidor.

¿Qué es Cloud Foundry, sin marketing y para un desarrollador?

Cloud Foundry es una iniciativa detrás de la que está VMware como gran esponsor, y que ofrece soporte para ‘cloudificar’ nuestras aplicaciones con la consiguiente escalabilidad, estandarización de la infraestructuda y todo eso.

Dejando aparte los discursos de estrategia y márketing, y centrándonos en el impacto para los desarrolladores Spring, la cosa apenas se complica mucho por ello. Y esa es la gran virtud.

Cloud Foundry proporciona una infraestructura estable y estándar (p.ej. Java 1.6 o 1.7, tc Server/Tomcat, Spring, etc.) que incluye diversos servicios (MySql 5.1, Redis, etc.), contra la que podemos desarrollar y desplegar nuestras aplicaciones.

Para los desarrolladores existe la posibilidad de usar como sustituto de la cosa real una máquina virtual que proporciona toda la infraestructura y servicios de Cloud Foundry, y que podemos usar para desarrollar en local. Básicamente es a esto es a lo que se llama Micro Cloud Foundry, ni más ni menos.

Vale, pero ¿cómo afecta todo esto a mi código Spring? Pues en muchos casos el impacto es cero: por ejemplo, en nuestra aplicación se ataca una base de datos MySql, digamos ‘killer_demo’, con el usuario ‘myUser’ y la password ‘pwd’. ¿Qué cambios hice con respecto a una aplicación Spring a desplegar en nuestro propio entorno? Cero. En mi caso utilicé Spring beans para atacar MySql, usando la siguiente configuración

    <beans:bean id="springDataSource" 
     class="org.apache.commons.dbcp.BasicDataSource">
       <beans:property name="driverClassName" 
          value="com.mysql.jdbc.Driver" />
       <beans:property name="url" 
          value="jdbc:mysql://localhost/killer_demo" />
       <beans:property name="username" value="myUser" />
       <beans:property name="password" value="pwd" />
    </beans:bean>

    <beans:bean id="springEmf"
      class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        <beans:property name="persistenceUnitName" 
           value="killer_demo_pu"/>
        <beans:property name="persistenceProviderClass" 
           value="org.hibernate.ejb.HibernatePersistence"/>
        <beans:property name="dataSource" 
           ref="springDataSource"/>
    </beans:bean>

La cosa es que cuando enviamos la aplicación a un sistema que soporte Cloud Foundry, el correspondiente mecanismo automágico le echa un vistazo a los Spring beans y los reconfigura. Así, el sistema ve que tenemos una fuente de datos que utiliza un usuario ‘myUser’ y una contraseña ‘pwd’: si no existe una base de datos la crea automáticamente, con un nombre que se saca de la manga, y por supuesto trabaja con usuarios y contraseñas generados del mismo modo.

Y lógicamente sustituye los valores proporcionados por nosotros por los valores que se ha sacado de la manga en los propios beans.

Obviamente, si la configuración de la aplicación se complica o deseamos un mayor control, puede llegar a ser necesario dar información específica a Cloud Foundry, información que se proporcionará vía configuración de Spring. Aún así, el impacto en el resto del código fuente será cero.

Como os podéis imaginar, la cosa funciona de forma similar si en lugar de usar Java+Spring se usa otra infraestructura soportada, como Scala, Grails, Node.js, etc.

¿Y cómo configuro o despliego aplicaciones en Cloud Foundry?

Para tareas tales como desplegar y configurar la aplicación (¿cuánta memoria le vamos a dar?) y los servicios que usa, deberemos utilizar vmc o el correpondiente plugin de Eclipse.

Por ejemplo, para instalar myApp.war por primera vez, tendremos que ejecutar

vmc push myApp

O, para ver las aplicaciones instaladas, bastará con

vmc apps

Desde luego, puede ser necesario controlar el entorno de manera mucho más fina por parte de un administrador, y este puede obtener acceso a los distintos servicios mediante tunneling, algo que no tiene por qué afectar al código fuente.

Micro Cloud Foundry está muy bien, pero…

… eso de tener que enviar un war con los cambios mientras desarrollas no es que favorezca el desarrollo ágil, la verdad.

Personalmente prefiero desarrollar mis aplicaciones en local, dado que me permite un desarrollo mucho, mucho más ágil: si se hace con cuidado, se puede desarrollar sin problemas la aplicación contra un Tomcat local, una base de datos local y cualesquiera otros servicios locales, y luego moverla a Micro Cloud Foundry para verificar que no hemos hecho nada raro.

Un detalle puntual: dado que Micro Cloud Foundry instala nuestra aplicación como si fuera la ROOT de Tomcat, no importa cómo llamemos al WAR que desplegamos, será conveniente que configuremos nuestra aplicación y el Tomcat local para que tenga esto en cuenta: aquí hay información relevante al respecto.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s