El servicio en la nube pasó a ser clave para muchas empresas que necesitan de recursos informáticos, como almacenamiento, procesamiento y software, todo a través de internet. De esta manera, en lugar de tener que comprar y mantener su propia infraestructura de TI, los usuarios pueden acceder a los recursos que necesitan a través de proveedores de servicios en la nube como Google Cloud, Amazon Web Services, Microsoft Azure, etc.
Con los avances de los últimos años, tener estos servicios en local (on premise) dejó de ser práctico, incluso rentable, ya que la nube es a día de hoy la mejor opción para desplegar nuestros servicios. Entre las ventajas que destacamos están los costes, que disminuyen drásticamente ya que no dependemos de un mantenimiento de hardware o que un equipo de soporte técnico tenga que desplazarse físicamente donde alojamos nuestros servidores donde montamos los servicios.
En el siguiente post veremos como implementar un servicio en la nube.
1. Preparación de la aplicación
La preparación de nuestra aplicación puede ser relativamente sencilla, ya que la diferencia entre alojar nuestra aplicación en local y en la nube no siempre implica grandes cambios. Un punto a tener en cuenta es si buscamos una plataforma como servicio Paas o una infraestructura como servicio IaaS.
La diferencia reside en que si queremos el control total del hardware que vamos a “alquilar” al proveedor de la nube iremos por un servicio IaaS. En cambio si lo que buscamos es un enfoque total al desarrollo sin preocuparnos por la implementación y administración de nuestra aplicación, debemos ir por un servicio PaaS.
2. Antes de empezar
Antes de comenzar debemos determinar hasta qué punto buscamos tener control de la infraestructura, como mencionamos antes si vamos un por un servicio Iaas o Paas. Con esto resuelto debemos plantearnos si vamos a ir por un modelo donde despleguemos todo en un servidor o si por el contrario preferimos modernizar nuestra metodología y transformar nuestro aplicativo en microservicios.
Este último paso al momento de migrar a la nube puede hacer que se alargue el proceso, pero con grandes ventajas, como el hecho de separar en clústers lo que actualmente se tiene en un servidor, poder distribuir las cargas e incluso orquestar todo desde un mismo lugar, como podría ser con GKE (Google Kubernetes Engine).
También hay que entender con las bases de datos el hecho de cómo vamos a conectarla entre los distintos servicios. Una vez más si todo está hosteado en un solo servidor, lo cual si bien disminuye la dificultad de migrar porque se mantiene una estructura muy similar a la on-premise, por otro lado se estarían desaprovechando todas las virtudes de migrar a la nube.
3. Creación e implementación
Para ejemplificar cómo realizar la creación e implementación tomaremos a Google Cloud como nube de destino.
En primer lugar, debemos crearnos un proyecto dentro de la nube, idealmente si somos una empresa podemos contar con licencias de Google Workspace ya que nos permitirá de forma automática tener una organización dentro de GCP y así poder tener todos los proyectos bajo esa organización, heredando permisos y restricciones. No es obligatorio ya que podremos utilizar Cloud Identity para crear la organización, pero de esta manera es más sencilla y tendremos todo dentro del ecosistema Google.
A continuación debemos buscar el módulo dentro de la nube que supla las distintas necesidades, para esto hay varias opciones, siempre Google es una de las primeras maneras de obtener información, pero también tenemos herramientas como el developer cheat sheet donde estan todas las opciones disponibles en un solo panel, separado por utilidades, como “Compute”, “Storage”, “Database”, “Data Analytics”, “ML/IA” y otras más. Dentro de cada uno además tendremos los módulos específicos y links a una explicación en profundidad de para qué sirven y para a que tipo de necesidad están desarrolladas.
Esto potenciado con la calculadora de precios donde en pocos pasos tendremos un estimado de cuáles serán los costes de nuestra infraestructura en la nube. El único inconveniente en la calculadora es que hay que tener un mínimo conocimiento de la herramienta, pero con muy poca información igualmente podremos sacar un estimado.
Con este paso resuelto, ahora comienza el proceso de implementación o migración en el caso de que ya tengamos algo en local. Basta con conocer el abanico de soluciones que tenemos a disposición para ver cuál se ajusta mejor a nuestras necesidades. Por ejemplo, si necesitamos un servidor iremos a “Compute Engine”, pero si además tenemos una base de datos SQL, en vez de dejar todo en ese servidor podemos contratar “Cloud SQL”, módulo que se enfoca 100% en el almacenamiento de bases de datos MySQL, SQL Server y Postgresql.
Si nos decantamos por un sistema de microservicios podemos optar por “Cloud Run”, y si poseemos muchos de estos microservicios podemos irnos directamente a Kubernetes y orquestar todos los clústers desde un solo lugar.
Además, una gran ventaja del cloud computing es que tenemos algo que se llama elasticidad, lo que significa que si en un servidor tenemos ciertos requerimientos técnicos, pero que pueden variar, ya sea vCPU o vRAM, podemos hacer que estas capacidades vayan variando, para que los costes se ajusten al uso real y no al sobredimensionamiento, como pasa en el caso de onpremise, para estar cubiertos de consumos picos.
Un punto clave a tener en cuenta es que al momento de trabajar en una nube como la de Google es que existen partners como uCloud, quienes se especializan en acompañar en este proceso, ya sea asesorando o realizando toda la implementación. Esto da como resultado no sólo un mayor porcentaje de éxito, sino la optimización de los recursos que se vayan a utilizar.
4. Compruebe que la implementación se haya completado correctamente
Para poder estar seguros de que todo funciona no basta con utilizar la aplicación que hayamos implementado. Si es correcto comenzar probando las conexiones, ver que los datos se estén almacenando correctamente, que los servidores respondan en el tiempo esperado, etc.
Sin embargo es muy importante hacer pruebas de estrés, donde forcemos los recursos desplegados para determinar si al momento de tener grandes consumos va a responder como esperamos. Las pruebas más grandes y complejas pueden demorar semanas y ser costosas, pero para un equipo que parte de algo más pequeño, podrían tomar 2 caminos. Por un lado, generar una gran cantidad de pedidos al servidor diseñando un script, y por el otro, lanzando una fase beta de la aplicación y evaluando el comportamiento de la misma.
Este proceso sobre todo en pequeñas aplicaciones a veces no se lleva a cabo, lo cual puede ser un problema, no solo en rendimiento sino en costes. Una falla en la configuración de reintentos dentro de una función puede generar un consumo inesperado que sobrepase el presupuesto estimado. Claro está que con una correcta implementación esto no debería pasar, pero nunca está de más esta fase de pruebas, donde evaluamos capacidades, rendimiento, costes, latencia y las métricas que consideremos necesarias.
5. Siguientes pasos
Como paso siguiente, en el caso de haber optado por servidores, podría ser la transformación a microservicios, de los cuales ya mencionamos algunas de las bondades. También está la posibilidad, en caso de tener todo en un solo servidor, de segmentar las bases de datos a servicios específicos para esto, como Cloud SQL, Cloud Spanner o BigTable.
Si bien idealmente se hace desde un principio, en caso de no haberlo hecho estaría muy bien automatizar un sistema de backups para estar tranquilos que frente a cualquier inconveniente tenemos disponible un sistema de disaster recovery sobre el cual accionar.
Finalmente como paso extra y opcional podemos profundizar los conocimientos realizando pruebas. Muchas de las funcionalidades ofrecidas por la nube de Google tienen una capa gratuita, la cual nos permite activar APIs y utilizarlas sin que implique un coste. El detalle de qué módulos tienen esta opción se las dejamos en este link, ahí podrán encontrar no solo cuales sino el límite que tienen de consumo gratuito. Una gran parte renueva este consumo mes a mes, por lo que, mientras no nos excedamos podemos hacer nuestras pruebas sin preocuparnos de un tiempo limite.
