Introducción
A todos se nos llena la boca cuando hablamos de proveedores de Cloud y proyectos mogollónicos que tienen que escalar como demonios y soportar un tráfico de la leche sin importar el coste de la nube, pero.... Si trabajas en modo Bootstrap o quieres desarrollar tu proyecto personal, no todo va a ser quemar dinero como si no hubiera un mañana, igual sólo necesitas un servicio mínimo y que te den la opción de ir escalando conforme vayas creciendo.
En concreto vamos a cubrir un escenario muy simple pero común, y es el de subir un frontal (podría tener un backend integrado en despliegue, o usar dos servidores separados), y una base de datos.
Para este caso, ¿qué opciones tengo? ¿cuánto me puede "salir la broma"(*)?
(*) En este post te damos precios aproximados, puedes comprobar los precios actuales y exactos en los enlaces que te facilitamos para cada proveedor de nube.
TL;DR;
El objetivo que nos planteamos es tener un entorno de desarrollo a coste cero o muy bajo, un entorno de producción para arrancarnos con una instancia que salga por debajo de los 15 € / mes y la base de datos por debajo de los 10 € / mes, y con recorrido para escalar en vertical e incluso horizontal (gastando más claro :)).
Escalar en vertical es aumentar la potencia de la máquina (más memoria, más cpu...), escalar en horizontal es aumentar el número de máquinas (para esto te hace falta también que la arquitectura de tu aplicación esté preparada para esto), si quieres leer más sobre esto en este post explican más en detalle escalar en horizontal vs vertical.
¿Oye eso de 15 € mes y 10 € mes suena a poco no? Depende:
Cuando hables de estas cifras multiplícalas por 12, el coste anual siempre hace "más pupa" y es lo que vas a tener que pagar de todas todas.
A poco que te metas con más de un side project, empezarás a tener más "champiñones" (de hecho si acabas con un buen número de proyectos pequeños te empezará a traer cuenta pasar a otro tipo de solución).
Siempre salen gastos extras asociados, que si quiero usar una storage o una CDN, que si tengo que pagar por el tráfico, que si quiero un balanceador de carga, que si quiero un certificado de seguridad, ...
Te toca también ver como evoluciona tu aplicación y si pega un repunte en tráfico igual te tienes que plantear subir a instancias más grandes e incrementar costes.
¿Te imaginas contratar un camión para llevar una caja de zapatos? Pues eso es lo que te puedes encontrar si no te informas bien antes de contratar un servicio de nube.
Además de esto, decidir que proveedor de nube elegir no es sólo mirar coste de máquina por minuto, tienes que evaluar:
Servicios extras que no te esperabas, tales como: pagar por el tráfico que tenga tu sitio (eso se puede medir en GB de transferencia), si tienes que pagar por un balanceador de carga desde el minuto cero...).
Coste indirectos: azúcar vs tener que configurar tú mismo, todo a bajo nivel (certificados de seguridad, cierto nivel de protección básico contra hackeos, etc...).
Conocimiento necesarios para hacer deploy: desplegar más pegado a infraestructura (lo que se suele decir más pegado al hierro, aunque aquí estamos en la nube) IAAS vs azúcar SAAS.
Estudiar bien precios y letra pequeña, estar al tanto de temas tales como:
Ofertas temporales vs precios finales.
Servidores que se duermen o dejan de funcionar cuando han consumido X horas de CPU.
Diferencia entre servicio compartido y dedicado
Qué mínimo de coste implica una instancia lista para arrancar en producción.
Si tu código está bien hecho y la tecnología que has elegido consume pocos recursos, esto se nota mucho: esforzarte porque tu software consuma menos que un mechero no sólo es bueno cuando quieres escalar como una bestia, también te va ser de gran ayuda cuando quieras contratar una máquina con un coste razonable para empezar.
Para el escenario que hemos comentado, tenemos las siguientes opciones:
API / Front (desplegamos API y Front en misma instancia)
Heroku
En Heroku puedes contratar Dynos ¿Qué es esto? Heroku llama Dynos a contenedores Linux virtualizados y aislados que están diseñados para ejecutar procesos de código basado en los comandos del usuario. Más información acerca de los dynos y con la tabla de precios y características de las diferentes máquinas.
Puedes arrancar con 7€ al mes (este precio te cubre hasta 2TB de trafico mensual, si te pasas de ahí en principio no te comentan en claro que puede pasar en este escenario), a este tipo de instancia le llaman Hobby son instancias para aplicaciones con poco tráfico y que no se duermen.
Antes te ofrecían Dynos gratuitos que se dormían, ideal para un entorno de desarrollo simple, de un tiempo a esta parte han dejado de dar este servicio. Lo han sustituido por Eco Dynos (5€/mes), una máquina con las mismas prestaciones que la Hobby pero se duermen a los 30 minutos de inactividad y tienes 1000 horas de uso por mes.
Puedes ver en este enlace los precios de cada Dyno (haz scroll hacia abajo para ver la tabla). Normalmente deberían estar en su página de pricing pero a la fecha de escribir este post todavía no la han actualizado.
Ojo que con la versión mínima lo que tienes son 512Mb de RAM y 1 core CPU compartido, tienes opciones de escalar en vertical (más memoria, más CPU), el siguiente paso está en 25 € mes.
Vas con mucho azúcar (por ejemplo te gestionan el certificado de SSL por ti, o te dan muchas facilidades para poder subir tu código), ya sea aplicaciones en un lenguaje determinado (NodeJS, Python, etc) o directamente tu propia imagen de Docker.
Render
Al rebufo del anuncio de Heroku de dejar de ofrecer Dynos gratuitos han nacido iniciativas como Render.
Ofrecen hosting gratuito para sitios estáticos (hasta 100 Gb de ancho de banda, CD desde Git, SSL, y una CDN incluida): esto esta muy bien si subes una aplicación de tipo SPA que ejecutan toda la lógica en cliente.
Si quieres tener tu capa de api rest o similar (incluso si usas Docker para generar tu servicio), también hay una opción gratuita, y los planes de pago empiezan en 7€ al mes aprox.
Es puro azúcar para subir tu código, pero tiene opciones más limitadas que Heroku.
Un tema interesante es que te ofrece el servicio para hacer diferentes deployments por cada Pull Request, así puedes probar fácilmente una rama en un entorno antes de hacer el merge (funcionalidad incluída incluso en el tier gratuito). Esto no te lo da Heroku :).
Una de las preguntas que te puedes hacer es ¿Dónde está el truco? Las condiciones son muy buenas El principal miedo con esta solución es que está arrancando y podría pasar como con Heroku que si despega, una grande la comprara y hay riesgo que de un día para otro cambien las condiciones.
Railway
Railway es otra alternativa con tier gratuito pero mucho más simplificada que Render
Ofrece hosting gratuito de sitios estáticos, así como servicios en varios lenguajes como NodeJS, Deno, Python, etc. a través de las builds con Nixpacks (alternativa a los Buildpacks de Heroku), e incluso aplicaciones que usen Docker.
Con esta opción gratuita, te dan un crédito de 5€/mes (no hace falta meter tarjeta de crédito, basta con que valides la cuenta con Github) y un límite de 500 horas de uso. Lo bueno es que el servicio no se duerme, esta continuamente andando excepto si se supera el límite de horas o los 5$.
Te ofrecen una máquina de 512MB RAM, 1GB de disco y 2vCPU.
Además ofrecen 2 planes más, el de Developer con límites de 8GB RAM y 8vCPU por servicio y 100GB de disco compartidos entre todos los servicios. Es pago por uso, es decir, te van calculando según el uso que hagas de CPU y RAM. Aproximadamente cobran la RAM 10€/GB al mes y de CPU 20€/vCPU al mes.
El último plan es Team, que cobran 20$/usuario (además de lo que gastes en RAM y CPU) con limites de 32 GB RAM y 32vCPU por servicio y 2TB de discos compartidos entre todos los servicios.
Todos los planes tienen hasta 100 Gb de ancho de banda, CD desde Git o usando su CLI y multiples dominios custom con SSL.
Una pega de este proveedor de cloud es que se hace algo más complejo calcular cuanto vas a pagar por sus servicios.
AWS
La nube de Amazon, es el proveedor de cloud más grande del mundo.
Puedes arrancar con una máquina virtual por 5€ al mes y si creas una cuenta nueva te ofrecen una free tier durante un año (es decir una serie de productos a coste cero durante un periodo de 12 meses).
Hay máquinas más baratas pero montan arquitectura ARM (te puedes comer unos buenos minutos de build al convertir), y también puede que con las specs de las más bajitas que tienen no te den el mínimo para correr tu proyecto.
Para la versión más económica y pegada al hierro (EC2) prepárate que te lo tienes que cocinar tu todo (ahí tienes tu instancia... dale caña, desde gestionar certificado SSL, a que si se reinicia la máquina cambia la IP, si no cuentas con IP estática...).
Si te vas a una opción con más ayuda (EBS), te va a tocar pagar más al mes, o ponerte a configurar y contar con que te dan 5 IPs estáticas por area geográfica.
También tienes disponible una opción relativamente reciente que es Amplify que es un servicio SAAS que te da una solución completa pero corres riesgo de acabar muy acoplado a AWS.
Azure
Aquí nos vamos a full SAAS :) (hay otras opciones, pero no nos complicamos).
Te da opciones gratuitas para desarrollo (instancias compartidas que tienen una serie de horas de CPU asignadas, cuando te comes ese tiempo... chin pon hasta el mes que viene).
Si te vas a opción de pago, y con certificado SSL incluido te puedes pillar una máquina básica Linux con un core y 1,75Gb de RAM por approx. 13€ al mes (es divertido porque pese a que esta nube es de Microsoft, en algunos casos las instancias Linux son más baratas que las Windows).
Como con Heroku cuentas con mucho azúcar y además estás trabajando con uno de los proveedores de nube más grandes del mundo.
Puedes calcular precios de forma aproximada en Azure Pricing Calculator.
Base de datos
En nuestros casos elegimos el hosting de Mongo Atlas:
Para arrancar tienes una instancia compartida gratuita, que va bien para probar en desarrollo.
Una vez que quieres pasar a producción, puedes optar por una instancia compartida de pago (9€ al mes approx.), o tener tu cluster dedicado por unos 57€ al mes approx., lo bueno de esto es que ahí puedes meter todas las bases de datos que quieras.
También existen otros proveedores en la nube si tu base de datos es PostGre, SQL Server, ...
Hasta aquí el resumen, ¿Quieres ver esto en detalle? Vamos al lío...
Temas a tener cuenta
A la hora de elegir el proveedor y solución que más nos interesa, debemos de evaluar una serie de factores tales como:
Características de la máquina (memoria RAM, CPU, disco).
Qué nivel de escalado manual y/o automático permite.
Si nos provee de una gestión automática de certificados SSL.
Configuración del dominio con o sin gestión de IP's
Configuración de la zona geográfica donde hacer el despliegue.
Facilidad para inyectar variables de entorno.
Configuración de la máquina (si ya viene con todas las herramientas necesarias instaladas o tenemos que hacerlo nosotros).
Si permite habilitar HTTP/2 (esta es una gran limitación de Heroku, sin embargo, en otros proveedores tienes la opción).
Conexión SSH a la máquina desplegada. Esto nos permite ver su estado y por ejemplo en el caso de que haya ocurrido un fallo, acceder a los logs, etc.
Acceso a métricas y logs. La mayoría de los proveedores ya te dan algunas métricas básicas, aunque siempre está la opción de contratar un servicio externo.
Opciones que te den para poder desplegar tu aplicación, por ejemplo: que te permitan realizar un despliegue desde Github Actions u otra pipeline externa al proveedor.
Si aceptan un despliegue mediante Docker u otra tecnología de contenedores. Esto abre la puerta a miles de aplicaciones diferentes, sin necesidad de estar atado a que tu proveedor tenga la máquina preparada con las herramientas del lenguaje que sea (por ejemplo nodeJS) para poder ejecutar tu aplicación.
Opciones
Heroku
Heroku hasta hace poco ha sido la opción por la que muchos desarrolladores se arrancaban, ¿Por qué?:
De primeras no te pedía ni tarjeta de crédito para darte de alta (esto ya no es así).
Te dejaba subir tu desarrollo sin tener que pagar nada (lo subías a un Dyno que se dormía al X tiempo, pero para hacer pruebas o tener un entorno de desarrollo iba genial).
Si quieres irte a un entorno que no se duerme, tienes un punto de partida mínimo por sólo 7$ (512 Mb Ram, 1 core).
Te da mucho azúcar para poder subir tu sitio de una forma cómoda y te gestiona temas tales como el certificado SSL por tí.
Si quieres saber lo que es un Dyno puedes irte a la sección anterior TL;DR;
Si os fijáis, en alguno de los puntos anteriores he estado hablando en pasado, ¿Por qué? Hace un tiempo que SalesForce (un gigante) compró Heroku, y han decidido que ya no es viable mantener los Dynos de prueba gratuitos, esta ha generado gran polémica en la comunidad y daría para otro post :).
Para saber más sobre precios: aunque su página de pricing todavía no la han actualizado, en este post puedes ver más información acerca de las diferentes máquinas que ofrece Heroku y aquí otra tabla con los precios
Render
Con este proveedor podemos desplegar nuestros servicios incluso a partir de un Dockerfile. Cuando usemos el plan gratuito la máquina se va a dormir a los 15 min de inactividad, pero por otro lado te están dando:
Una máquina de 512MB de RAM con CPU compartida.
Poder elegir entre varias zonas geográficas
Despliegue automático conectado directamente a Github. Es decir, todos los comandos de docker build, docker run están definidos en el portal de Render dentro de las settings del proyecto, y una vez que detecta un push en la rama elegida del repositorio de código, inicia el compilado y despliegue del nuevo código en esa máquina que has contratado. Si quisieras lanzar un despliegue desde Github Actions u otra pipeline, te ofrecen una API REST para lanzar un deploy (eso si, igualmente sigues definiendo los comandos docker build y demás en su portal)
Puedes hacer un rollback rápido a una versión anterior, pulsando un botón.
Tiene una interfaz intuitiva para poder añadir variables de entorno.
Permite hacer un despliegue de una Pull Request de Github, dentro de la misma aplicación, por lo que genera una nueva instancia del servicio para poder comprobar el despliegue antes de mezclar a la rama principal.
Además te da unas métricas muy básicas del uso de tu app y acceso a logs.
Otras ventajas interesantes: te ofrecen HTTP/2 por defecto, un dominio automático con SSL y poder añadir tu propio dominio.
Por otro lado, si tu aplicación crece o necesitas hacer gestiones a más bajo nivel, puedes conectarte mediante SSH a la máquina o aumentar el disco duro, lanzar un cron job, tener servicios privados o tener procesos en background (para esto ya te tienes que ir a un plan de pago).
Railway
Railway es un proveedor aun más simplificado que Render y Heroku. Una vez que te identifiques con tu cuenta de Github (siguiendo esta aproximación no hay necesidad de añadir tarjeta de crédito), puedes crear un proyecto, y dentro de ese proyecto añadir tantos servicios como quieras.
Eso si, con el plan gratuito, te dan 5 $/mes y 500horas/mes de límites compartidos entre todos los servicios. Si superas alguno de los dos límites, las máquinas se apagan hasta que se renueve el mes. Es decir, si tienes mucho tráfico y empiezas a consumir RAM y CPU se te va gastando el límite de los 5$, sino, a los 21 días se apagan (approx.).
Como puntos a favor:
Cuentas con una máquina de 512MB de RAM con 1 vCPU por servicio.
Tienes despliegues automáticos desde Github o usando su CLI.
Puedes desplegar tu aplicación con un Dockerfile, aunque ellos hacen la ejecución del docker build y docker run, para ello tiene que estar en la ruta raíz del proyecto el fichero o indicarle la ruta alternativa.
Puedes hacer un rollback rápido a una versión anterior, pulsando un botón.
Tiene una interfaz intuitiva para poder añadir variables de entorno.
Te provee un acceso a métricas muy básicas del uso de tu app y acceso a logs.
Te da HTTP/2 por defecto, un dominio automático con SSL y poder añadir tu propio dominio (ellos te proveen del certificado SSL de tu dominio).
Peeeero:
No puedes elegir zona geográfica donde hacer el despliegue.
No puedes acceder mediante SSH u otra alternativa a la máquina (ni con el plan de pago).
Además, los planes de pago por uso son relativamente caros comparados con otros proveedores (RAM 10$/GB al mes y de CPU 20$/vCPU al mes).
AWS
En AWS tienes tres opciones:
Irte a IAAS (más pegados al hierro) (EC2).
Irte a una opción mixta (hierro con azúcar) (EBS).
Irte a SAAS (puro azúcar) (Amplify).
También si creas una cuenta nueva te ofrecen una free tier el primer año (comprueba primero si puedes aplicar a la misma y qué productos concretos son lo que puedes usar sin coste).
EC2
Los precios de EC2 son muy buenos, ¿dónde está el truco? en que te lo tienes que currar tu todo:
Por ejemplo: no tienes SSL de forma automática, o bien te compras un certificado, o te pillas uno en Let's Encrypt, y te haces un cron job para renovarlo cada X tiempo (otros proveedores te ocultan está complejidad y te lo hacen por ti).
Tienes que configurar la máquina para que tenga instalado Docker, Nginx o cualquier librería / tecnología que necesites.
También es un lío el tema de los dominios, los DNS de la máquina están asociados a la IP, y estas IPs son dinámicas, por lo que si se te resetea la máquina asociada, pierdes la IP que tenías. En este caso, puedes optar por obtener una Elastic IP que es una IP fija (en el apartado de EBS se habla un poco más en detalle) y asignarla a tu máquina EC2 o configurarla de manera que lance un evento que te actualize el registro en el DNS (esto va bien si estas en el DNS de AWS: Route 53 O:-)).
No tienes una interfaz para las variables de entorno, si quieres una forma segura de hacerlo, tienes que contratar un S3 (su servicio de storage), habilitar la encriptación de estos ficheros (lo bueno es que esto es transparente para nosotros) y hacer que la máquina recupere el fichero del S3.
Para poder hacer un despliegue desde Github Actions, tienes que crear claves SSH para conectarte usando este protocolo, crear un usuario con permisos apropiados para poder acceder a la instancia EC2, al Registry de Docker de ellos o cualquier otro (si lo usas para compilar y ejecutar tu aplicación), hacer que tu EC2 también tenga permisos para hacer un pull de la imagen de Docker, además de tener que recuperar la IP de la máquina para poder conectarte, ya que como hemos comentado, esta IP puede cambiar. Es decir, en algún punto de éstos, sobre todo dando permisos, podemos equivocarnos o incluso dejar una puerta abierta a un fallo de seguridad.
Si elijes arquitectura ARM (más barata), te puedes encontrar con algún problema desagradable, y es que por ejemplo para hacer un build con Github Actions tienes que usar BuildX y el emulador (QEMU ) y te puede pasar un proceso de build de 3 minutos a 23 (Sí, los minutos de build son dinero y tiempo :)).
Un punto positivo es que aquí tienes via libre para conectarte a la máquina con SSH desde la propia web de AWS o tu misma máquina.
Tienes todo elgrano fino de personalización que quieras, ya que te lo tienes que currar todo.
¿A que ahora te cuadra que hayan proveedores de cloud tipo SAAS que por debajo usan AWS?
EBS
Si por otro lado buscas algo que tenga más azúcar, puedes usar EBS (Elastic Beanstalk):
Te permiten usar hasta 5 IPs fijas por zona geográfica (si no usas balanceador de carga puedes crear hasta 5 sitios, porque automáticamente te asignan una IP fija, si necesitas más sitios te va a hacer falta tirar de servicios adicionales, esto implica coste y complejidad adicional, o tirar del hack de desplegar en diferentes zonas geográficas para obtener 5 IPs fijas más).
El método para subir a producción es más sencillo y además puedes elegir despliegue con Docker y te configura la máquina con la instalación necesaria.
Te provee de una interfaz gráfica para establecer los valores de las variables de entorno (ya no te hace falta tirar de un S3).
Por debajo, te crea una máquina EC2 con las características que tu elijas, por lo que tienes la ventaja de poder seguir conectándote con SSH.
Un punto negativo es que sigues sin tener SSL automático, tienes que currárterlo igual que antes (o bien contratar uno, o tirar de Let's Encrypt y un configurar un cron job para actualizarlo de forma automática cuando vaya a caducar).
Sin embargo, si usas un balanceador de carga, si que puedes asociarle un certificado SSL de AWS de forma gratuita, lo enlazas al balanceador y repartes el tráfico entre las diferentes instancias. Aquí ya no tienes que tratar con las IP fijas o dinámicas de las instancias, simplemente apuntas tu dominio al balanceador de carga. Eso si, prepárate para pagar más, además del sobrecoste del balanceador también te toca pagar por el tráfico que gestione el mismo (el application load balancer te puede salir por unos 19 € mes más el tráfico que genere).
¿Dónde está el truco? Que a poco que tengas varios sitios web subidos te comes esas 5 ips fijas y ya te toca añadir un application load balancer para tener más sitios que compartan IP's (y la cosa se te puede subir a 50$ al mes, y además tienes más dolores de cabeza como por ejemplo configurar el SSL en el balanceador de carga para múltiples dominios o tener un balanceador de carga por aplicación), ojo que si tu sitio tiene tráfico, un buen modelo de negocio, etc... es un precio y solución técnica más que válida.
Una ventaja de AWS es que te permite abonar tu factura mensual por transferencia bancaria, cosa que en otros proveedores o bien no es posible (sólo te dan opción de tarjeta de crédito), o tienes que generar un gasto en nube abultado al año.
Amplify
En este caso, Amplify lo que ofrece es una solución completa para desarrollar una aplicación web / mobile usando sus propios servicios y librerías:
Para la parte frontend: soporta tanto frameworks/librerias web (React, Vue, Angular, NextJS, Gastby, etc.) como tecnologías para aplicaciones móviles (Android, Swift, Flutter y React Native).
Para la parte backend API: soporta GraphQL y REST API. Eso si, siempre tirando por una solución serverless como AWS AppSync GraphQL o Amazon API Gateway. En este ejemplo de REST API de la documentación oficial, al final de todo, puedes ver que te recomiendan hacerlo con uno de los dos servicios anteriormente mencionados.
Para la parte de base datos: tienen su propia tecnología Amplify DataStore.
Para el resto de servicios que pueden ser necesarios en una aplicación como storage de ficheros, push notifications, geolocalización, etc. te ofrecen sus propias librerías: por ejemplo, el servicio de storage es el S3 de Amazon y con la librería aws-amplify puedes conectar tu aplicación al bucket S3 para recuperar tus ficheros. Puedes ver un ejemplo del storage de Amplify en este enlace
Ademas, te ofrecen una herramienta visual, Amplify Studio, donde puedes generar estas aplicaciones e incluso utilizando Figma para después generar el código de tus componentes (Figma-to-Code React).
¿Qué ocurre con el deploy? En este caso, te dan la opción de conectar con un repositorio de código (Github, Bitcuket, Gitlab, etc.), tener dominios custom, ofrece una interfaz gráfica para variables de entorno, monitoring, Pull Request preview, pero, te puedes llevar sorpresas como:
Ellos tienen su propio servicio de pipeline con su correspondiente YAML para hacer las builds de tu proyecto. Es decir, olvídate de tener un sistema externo para compilar tu proyecto.
A fecha de la publicación de este post, no soportal ISR (Incremental Static Regeneration) de Nextjs. Aquí tienes un ejemplo con NextJS 13 y en los comentarios podrás ver que personal de AWS confirma esta limitación (están trabajando en ello).
O incluso que si quieres tirar por una solución containerizada, tienes que usar AWS Fargate, es decir, añadimos más coste a nuestro proyecto. Más información de la documentación oficial de Amplify sobre contenedores
Es decir aquí tienes un compromiso, por un lado te facilitan mucho el trabajo, y te dan soluciones completas, por otro, te casas con la plataforma, y te será más complicado poder migrar a otra solución en el futuro, esto tienes sus pros y sus cons:
Al darte soluciones y camino marcado puede que avances más rápido (puede ser interesante para tener un MVP rápido en una startup).
Al estar más atado al proveedor, te puedes volver yonki del mismo, y que si a futuro necesites migrar te sea más complicado
Si un día el proveedor discontinua el producto o decide meter un cambio que rompe, o cambiar política de precios, te puede hacer mucho daño.
El precio de todo esto, puede ser complicado de definir porque depende mucho del uso y de tu aplicación:
Aquí os dejamos la tabla de precios de Amplify junto con un par de ejemplos (abajo del todo), de cuánto seria la factura en un mes simulando unos escenarios de uso de una aplicación.
Para ponerle la guinda al pastel, dependiendo de los "servicios extras" que necesites para tu aplicación, habría que mirar el pricing de cada uno:
AWS AppSync para GraphQL
Amazon API Gateway para REST API
Amazon S3 para el storage de ficheros.
etc.
Azure
En Azure la forma más sencilla de desplegar es utilizar App Service, que nos ofrece esto:
Hay un servidor compartido free (cores compartidos, 1GB ram, 1Gb Almacenamiento), ¿Perfecto? Bueno para desarrollo..., para producción no nos vale ya que tiene un número de minutos al día disponible (después se paga y chin pon hasta el día siguiente :)).
Hay otra opción shared (9.49 USD a la fecha que se escribió este post), con los mismos recursos pero 240 minutos al dia en vez de 60 (sólo si es sistema operativo Windows), aquí tienes el mismo problema, además de ser un hosting compartido, tienes una cuota de X minutos al día, ... que cosa más triste que tengas un pico de tráfico y te quedes sin minutos (señor cliente, vuelva usted mañana...).
Así que nos tenemos que ir a instancias dedicadas, si nos vamos a la opción más pequeña: tenemos una B1 (1 Core, 1.75 GB RAM, 10GB almacenamiento) y un coste mensual aproximado de 13€ (este precio lo hemos tomado, a la fecha de este post, y con una instancia Linux).
Si quieres precios a fecha de hoy, puedes tirar con la calculadora de precios de Azure o viendo la tabla de precios por servicio (en este caso elige App Service).
Lo interesante de Azure:
Estás trabajando con unos de los proveedores de nube más grandes del mundo, eso te puede dar cierta estabilidad y te ahorra el tener que estar pendiente de si una grande compra al proveedor de turno y cambian precios de la noche a la mañana.
Puedes desplegar fácilmente desde github y con entornos dockerizados (utilizando el registry de Docker que quieras, simplemente tienes que darle permisos para que pueda acceder).
Te ofrece muchas opciones de zonas geográficas (parecido a AWS) donde desplegar tu aplicación o incluso geo-replicarla.
Te gestiona un certificado SSL de forma fácil como en Heroku.
En la versión de pago, puedes añadir un dominio custom y ellos te gestiona el certificado SSL de forma gratuita.
No tienes que preocuparte de que se reinicie la máquina y tengas que ir actualizando tu DNS.
Puedes habilitar HTTP/2 de forma fácil mediante una interfaz gráfica.
Cuentas con una interfaz intuitiva para añadir variables de entorno.
Tienes un buen recorrido de escalado en vertical y horizontal.
Al ir en modo SAAS tienes algo más de protección frente a hackers, no estás tan expuesto.
Tienes acceso a métricas y logs.
Te puedes conectar mediante SSH al contenedor que se está ejecutando (eso si, necesitas hacer una configuración en tu Dockerfile para ello).
En este ejemplo, os mostramos la conexión SSH que proporciona el portal de Azure a un servidor que está ejecutando un contenedor usando una imagen basada en node:16-alpine:
Una vez se ha conectado correctamente, para asegurarnos que estamos en la instancia del contenedor, hemos ejecutado el comando de docker para ver que efectivamente no lo tenemos instalado, ya que estamos dentro del contenedor (y no usamos Docker in Docker) y por otro lado, el comando node -v para ver la versión de NodeJS en la que se basa la imagen:
¿Y la base de datos?
En nuestro caso nos decantamos por Bases de datos documentales, en concreto MongoDB, incluso para micro proyectos, en este sentido muchos desarrolladores te dicen que no uses Mongo para un proyecto pequeño, en nuestros escenarios nos va bien elegir esta aproximación, las razones:
Si sabes modelar en documental y tu tipo de negocio se adapta, acabas creando estructuras muy sencillas de manejar.
Las consultas van como una moto (sobre todo si tienes más lecturas que escrituras).
MongoDB ATLAS (el hosting en la nube de Mongo) te ofrece arrancar en modo progresivo:
Primero te ofrece un cluster compartido gratuito con 512MB de almacenamiento (normalmente más que suficiente para un proyecto pequeño).
Después puedes evolucionar a un cluster compartido de pago por 9$ al mes, tienes 2GB de almacenamiento.
Más adelante cuando tienes varias bases de datos las puede consolidar en un cluster dedicado (10GB almacenamiento, 2CPU, y 2GB ram) por menos de 60 € al mes, está opción es bastante buena cuando manejas varios proyectos.
Si de ahí te hace falta escalar a más, es que tu negocio va bien, y con ellos puedes llegar a tener 320GB de almacenamiento, 64GB de RAM y 16 CPU, claro... pagando un buen dinero :).
Más info sobre precios en Mongo ATLAS
Si nos vamos a motores relacionales, algunas opciones que te puedes plantear:
En Azure puedes empezar usando una base de datos de tipo SQL Server (Azure SQL Database), te puedes arrancar por la Basic - B, por algo menos de 5 € al mes, también te ofrecen de otros tipos de motores de BBDD.
En Render te dan hosting de PostGreSQL, y Redis empiezas por 0$ al mes (por tiempo limitado), el siguiente paso es pagar 7€ mes por 256Mb RAM, CPU compartida, y 1GB de RAM.
En Railway también te dan hosting de PostGreSQL, MySQL y Redis, e incluso de MongoDB.
¿Y si necesito subir ficheros a mi aplicación o una CDN?
En nuestro caso hemos probado con AWS S3 y Azure Blob Storage, los costes son razonables (te cobran por Gb almacenados y por transferencia de Gb) y te dan unas API's robustas. Cuando calcules precio, donde más duele es en el tráfico mensual que generas, pero salvo que muevas una burrada de datos, estamos hablando de costes razonables.
Ejemplo con los precios de Amazon S3
En el caso de CDN, en AWS tenemos CloudFront, y en Azure tenemos Azure CDN, también está CloudFlare, que es una CDN que te permite cubrir algunos escenarios más elaborados, tales como cacheo de DNS, etc...
Oye y ¿por qué usar un storage en la nube y no almacenar los ficheros en tu propio servidor?
Tu servidor puede ser relativamente fácil de atacar y te pueden robar información.
En tu servidor también te tienes que preocupar de tener backups y que no se pierda nada.
Normalmente los sistemas de storage ya se encargan de tener el contenido encriptado (seguridad).
Los sistemas de storage suelen exponer unas API's muy potentes para interactuar a nivel de desarrollo.
Conectar un S3 con una CDN es un juego de niños.
Conclusiones
Desplegar tu aplicación en la nube no es un tema baladí, tienes que tener en cuenta:
Qué complejidad va a tener tu aplicación.
Qué necesidad inicial tienes y cuales puede tener a futuro.
Qué equipo cuentas que pilote de infraestructura y DevOps.
Qué productos te ofrecen los diferentes proveedores de Cloud.
¿Me puedo fiar de lo que me aconsejen por defecto los proveedores de Cloud? La respuesta es **NO**, nos paso hace no mucho con un cliente que se quejaba de que la nube es cara, resultó que con su proveedor se dedico a darle a "siguiente / siguiente" en el wizard de provisión de servicio y le habían colocados unos maquinones por los que pagaba 500 € al mes, ... cuando era para un sitio simple con menos de 30 usuarios, ... se lo bajamos a 30 € mes y el sitio seguía funcionando perfectamente.
Seguramente para poner una primera versión de tu producto en la nube, te puede traer más cuenta centrarte en definir el producto, armar una buena solución a nivel de software y optar por SAAS para el despliegue, ahorrando así presupuesto en equipo e infraestructura, todo esto hasta que el producto empiece a tomar tracción y ya necesites pasar a una solución más elaborada o... en algunos casos, puede que incluso tu producto no necesite una infraestructura compleja (no te hace falta un cohete para ir a comprar el pan), esto me recuerda al meme de acabo de desplegar mi página personal en Kubernetes:
Por otro lado es muy importante, elegir opciones de hosting que te den la posibilidad de escalar/crecer, y también que te permitan desplegar de una forma que no te hagas dependiente de la misma (seguramente a futuro, o bien los planes de precios o tu producto tendrá otras necesidades y te plantearás migrar a otro proveedor de nube).
¿Front, Dev o Back?
Si tienes ganas de ponerte al día ¿Te apuntas a alguno de nuestros Masters Online o Bootcamps?