Poner en marcha una aplicación web sin preocuparse por la infraestructura subyacente es una de las promesas más atractivas de Google Cloud App Engine. En esta práctica se recorre paso a paso el proceso completo: desde preparar el entorno de desarrollo hasta ver la aplicación funcionando en producción, todo dentro de la consola de Google Cloud y utilizando Java 11 con Spring Boot.
¿Cómo preparar el entorno para App Engine con Java 11?
El ambiente estándar de App Engine soporta varios lenguajes de programación y, dentro de cada uno, distintas versiones. En este caso se elige Java 11 por sus mejoras respecto a Java 8 [0:22].
Para configurar el entorno en Cloud Shell es necesario:
- Verificar la variable
JAVA_HOME y apuntarla al JDK 11, que ya viene preinstalado [1:07].
- Instalar el plugin de App Engine para Java ejecutando
gcloud components install app-engine-java [1:29].
- Clonar el repositorio de muestras de código y ubicarse en el directorio
appengine-java11/springboot-helloworld [1:42].
La estructura del proyecto sigue la convención estándar de Java: un directorio src y un archivo pom.xml que gestiona las dependencias con Maven [2:05].
¿Qué estructura tiene la aplicación Spring Boot?
El archivo principal es el controlador que utiliza el patrón modelo vista controlador (MVC), propio de Spring. Este controlador expone un único endpoint en la raíz de la aplicación que devuelve un "Hello World" [2:35]. Antes de desplegar, siempre es buena idea probar localmente con mvn spring-boot:run y verificar el resultado en el puerto 8080 mediante la opción de preview [3:07].
¿Cómo desplegar la aplicación en App Engine?
Una vez confirmado que todo funciona, el despliegue se realiza con el comando gcloud app deploy, indicando el ID de proyecto [3:35]. Sin embargo, hay un paso previo indispensable: crear la aplicación de App Engine con gcloud app create --project=[ID_PROYECTO] [4:05].
Durante la creación se debe elegir la región de despliegue. La elección depende de dos factores principales:
- La ubicación geográfica propia y la latencia que se obtiene.
- La ubicación de los usuarios finales [4:35].
El proceso de despliegue involucra a Cloud Build, que se encarga de subir el código a Cloud Storage y desplegarlo en App Engine [3:50]. Si la cuenta de servicio de Cloud Build no tiene permisos adecuados, es necesario otorgarle el rol de Storage Object Viewer desde la consola de IAM [5:15].
¿Qué papel juega el archivo app.yaml?
El archivo app.yaml es la pieza de configuración donde se define el runtime, el tipo de máquina, la cantidad de RAM y el tipo de procesador [5:55]. Este archivo acompaña al artefacto (el archivo JAR) durante el despliegue.
Una vez completado, App Engine proporciona una URL pública accesible con gcloud app browse [6:20]. En la consola se puede verificar el servicio default con el 100 % del tráfico dirigido a la versión activa [6:45].
¿Por qué es crítico el manejo de versiones en App Engine?
Al realizar cambios en el código y volver a ejecutar gcloud app deploy, si no se modifica el identificador de versión, el servicio se sobrescribe en lugar de crear una nueva versión [7:25]. Esto significa que no se podrá hacer rollback porque no existe una versión anterior a la cual regresar.
La versión se controla desde el pom.xml, específicamente en el plugin de construcción. Se puede vincular a una variable de ambiente como BUILD_NUMBER, que normalmente proporciona la herramienta de integración continua (continuous integration) [8:25]. Con versiones diferenciadas es posible:
- Realizar bifurcación de tráfico (traffic splitting) entre versiones.
- Ejecutar pruebas A/B comparando comportamientos.
- Hacer rollback inmediato a una versión anterior estable [8:45].
Este control de versiones y la migración de tráfico, junto con el ambiente flexible de App Engine que utiliza contenedores, son funcionalidades que complementan el flujo de trabajo y permiten despliegues más seguros y controlados [9:15].
¿Ya probaste desplegar tu propia aplicación en App Engine? Comparte tu experiencia y las regiones que mejor latencia te ofrecen.
