- La experiencia de un desarrollador que migró de AWS a sus propios servidores y redujo su costo mensual de infraestructura a una décima parte, bajando de 1,400 dólares al mes a 120 dólares mientras obtenía un rendimiento de servidor más potente
- Los servidores bare metal ofrecidos por proveedores como Hetzner cuestan alrededor de 190 dólares al mes por 80 núcleos, entre 7 y 18 veces más baratos que instancias similares en AWS
- La razón por la que los ingenieros de nube se oponen a operar servidores propios es por la seguridad laboral y la dependencia de infraestructuras complejas, mientras que el costo real lo termina pagando el empleador
- La mayoría de los negocios pequeños no necesita funciones de nivel enterprise como alta disponibilidad, replicación multizona o failover automático, y un solo servidor puede manejar millones de solicitudes al día
- La administración de servidores se mantiene estable después de la configuración inicial, y gracias a herramientas de IA la barrera de entrada para operar servidores Linux está en su punto más bajo de la historia
Casos de ahorro en costos de nube
- Recientemente migró todos sus proyectos fuera de la nube y logró reducir 10 veces sus costos mensuales en AWS, ahorrando miles de dólares
- La factura mensual de AWS bajó de unos 1,400 dólares a menos de 120 dólares
- Obtuvo una infraestructura de servidores más potente por menos dinero
- El rendimiento mejoró 2 veces y además se liberó del vendor lock-in
- Cuando este tuit se volvió viral, descubrió dos cosas: muchos desarrolladores se interesaron en cómo lo hizo, y muchos otros mostraron un rechazo fuerte y una actitud confrontativa hacia la idea
- Desde una perspectiva de negocio, logró beneficios evidentes: reducir costos 10 veces, duplicar el rendimiento y salir de la dependencia del proveedor, pero aun así se encontró con una fuerte resistencia
Los intereses de los defensores de la nube
- La mayoría de quienes se opusieron tenían en su perfil palabras clave como "devops", "cloud engineer", "serverless guy", "AWS certified"
- Ellos no operan sus propios proyectos en la nube ni pagan personalmente esos costos
- Les da igual la factura de AWS de su empleador, y no sienten en carne propia el dolor de desperdiciar miles de dólares cada mes
- Por qué AWS les resulta conveniente
- Hace que parezca algo técnicamente complejo y los hace ver más inteligentes frente a otros desarrolladores
- Crea dependencia y lock-in, lo que los vuelve difíciles de reemplazar como empleados
- Como usar la nube garantiza sueldos más altos, no tienen incentivos para tomar decisiones eficientes para el negocio
- De hecho, mientras más compleja y enredada sea la infraestructura del negocio, más seguro se vuelve su empleo
- No te van a contar la verdad de que los servidores en realidad son baratos
Opciones baratas para rentar servidores
- Migró a Hetzner (sin afiliación, simplemente ofrece servidores baratos)
- Puedes rentar un servidor bare metal de 80 núcleos por menos de 190 dólares al mes
- En AWS, una instancia similar de la familia C5-C6 cuesta entre 2,500 y 3,500 dólares al mes, o sea entre 13 y 18 veces más
- Incluso con instancias reservadas sigue costando alrededor de 1,300 dólares al mes, unas 7 veces más, y además exige un pago adelantado de 46,000 dólares y un contrato de 3 años
- Las opciones de VPS también son atractivas
- Ofrecen una máquina de 48 vCPU por 300 dólares al mes, con flexibilidad total sin cuota de configuración ni contratos largos
- Ofrecen una máquina de 8 núcleos y 32 GB de RAM por 50 dólares al mes, suficiente para ejecutar todos tus proyectos al mismo tiempo salvo que manejes millones de solicitudes diarias
Comprar servidores y usar centros de datos
- A largo plazo, comprar un servidor sale más barato
- Puedes comprar un servidor rack mount con 44 CPU, 256 GB de RAM y 2 TB de NVMe SSD por menos de 1,000 dólares
- Por menos de lo que cuesta un mes de nube, puedes operar tu app durante años
- Opción de rentar espacio en rack dentro de un centro de datos
- Puedes rentar una jaula en datacenter o espacio compartido en rack con electricidad, internet, enfriamiento y seguridad
- Puedes buscar centros de datos en tu zona con sitios como DatacenterMap
- Para desarrolladores pequeños, esto es excesivamente complejo
- Hay que contratar ingenieros, negociar precios y pasar por un proceso engorroso
- Está pensado principalmente para empresas medianas y grandes, así que no es práctico para equipos pequeños
- En la práctica, es casi lo mismo que rentar un servidor ya montado con un proveedor como Hetzner, pero sin la carga de gestionar el hardware
Respuesta a la crítica de “eso sigue siendo nube”
- La crítica más común: "¿eso no sigue siendo nube?", "no te saliste de la nube, solo cambiaste de proveedor"
- Es una crítica que se pierde el punto central
- Lo importante es el valor de administrar tus propios servidores vs. dar por sentado el uso de la nube
- Si operas una pequeña máquina Linux para reemplazar servicios administrados y costosos como RDS, pagas entre 10 y 100 veces menos
- La mayoría de los desarrolladores le tiene miedo a los servidores y solo necesita un poco de ánimo para darse cuenta de que puede configurar uno barato por su cuenta
- En el mundo real, casi nadie necesita los caros servicios administrados de la nube; con unas cuantas cajas Linux y software común basta de sobra
- La discusión sobre nombres distrae de lo esencial
- Sea VPS, bare metal, on-premise o colo, el nombre no importa
- Claro que el servidor tiene que estar en algún lado; lo importante es si te quedó más dinero en el bolsillo o si se lo entregaste a los accionistas de Amazon
- Quienes insisten en esto actúan básicamente como gatekeepers
- "No lo estás haciendo de verdad; también tendrías que comprar tú mismo los switches, armar tú mismo el rack y conectar tú mismo los cables Ethernet"
- Es una discusión tóxica y floja, obsesionada con detalles superficiales para evadir el punto principal
Los costos de la nube son caros por naturaleza
- El intento de gaslighting de los defensores de la nube
- "Estás usando mal la nube", "si es caro es porque lo estás haciendo mal", "hay que saber usar la nube"
- Casi ninguno ha probado realmente las alternativas ni tiene experiencia real administrando servidores para sus propios proyectos
- El autor sí conoce AWS y hasta estudió certificaciones de AWS
- Verificó que la infraestructura no estuviera sobreaprovisionada
- Verificó que no estuviera pagando por servicios que no usaba
- Invirtió incontables horas en optimizar costos de AWS y hasta logró reducir a más de la mitad facturas mensuales superiores a 5,000 dólares
- Conoce serverless computing, instancias reservadas y todo lo demás
- Las instancias reservadas solo empeoran el problema: generan lock-in con el proveedor y te atan a un contrato de 3 años
- Si ya estás pensando en salirte de la nube, un contrato a 3 años es la peor opción posible
- La conclusión después de intentar todo: la nube simplemente es demasiado cara
La causa de la reacción adversa
- ¿Por qué tanta gente se preocupa por alguien que ahorra dinero?
- Dos conclusiones principales
- Su sustento depende de ello: si suficientes personas convencen a otros de hacer lo mismo, podrían perder el trabajo
- Discusión irracional nacida del miedo: en la última década montar todo sobre la nube fue la tendencia y eso creó millones de puestos de "devops" y "cloud engineers"; si ahora se vuelve tendencia salir de la nube, muchas carreras podrían acabarse
- Muchos desarrolladores saben en secreto que la nube no es tan buena como prometía al principio
- Ven que el gasto en AWS de su empleador es 10 veces más alto de lo razonable y aun así lo dejan pasar como si nada
- No quieren arriesgarse a molestar a su gerente ni a cargar con la responsabilidad
- Temen el costo político de contradecir a la persona más ruidosa del equipo
- AWS tiene un seguimiento casi de culto
- Las certificaciones los entrenan para memorizar páginas de ventas y descripciones de productos
- Tiene evangelists que predican el dogma en lugar del pragmatismo
- Inyecta miedo al mundo exterior (¡los servidores son peligrosos!, ¡no escalan!)
- Convierte a "cloud engineer" en una identidad, fácil de adoptar pero difícil de abandonar
- Como su sustento está en juego, los seguidores de AWS caen en argumentos irracionales
- Repiten uno por uno los puntos de las landing pages de ventas de AWS sin pensar si de verdad los necesitan
- Como discuten un sistema de creencias, la gente se vuelve irracional
Historia de la nube
- Antes todos operaban sus propios servidores
- En VPS, servicios de hosting, bare metal en datacenters, un cuarto oscuro en la empresa o hasta desde casa
- Todo el mundo estaba acostumbrado y se sentía cómodo entrando por SSH a una máquina
- A inicios de la década de 2010 comenzó una campaña de marketing/psyops alrededor de la nube
- Fue un movimiento deliberado para vender tecnología empresarial a startups en etapa temprana
- La estrategia era atraparlas lo antes posible para luego exprimirlas cuando consiguieran financiamiento
- La estrategia de AWS
- Empezó a ofrecer créditos especiales para startups
- Recorrió aceleradoras para subir a todas las startups a su plataforma
- El truco era simple: hacer que montar la infraestructura al inicio fuera extremadamente barato (¡gratis!), y luego, cuando crecieran, volverlo todo extremadamente caro para aprovechar el lock-in y dificultar la salida del ecosistema
- IBM Cloud tuvo una estrategia similar (evento de 2014)
- En ese momento todo corría sobre Heroku y funcionaba bien
- Surgía la duda: "¿qué es toda esta nube y cómo se usa?"
- Daba la impresión de que intentaban vender algo que no estaba diseñado para ellos
- Estas empresas han invertido millones de dólares en campañas para promocionar la nube y empujar a startups tempranas a adoptar tecnología enterprise
- La era de tasas de interés cercanas a cero en la última década también ayudó a llegar a esta situación
- Ahora existe un movimiento de contracultura
- Liderado en gran parte por @dhh y la comunidad de Rails
- Se siente mucho más fresco, correcto y alineado con la realidad de la mayoría de los negocios de software del planeta
La mayoría de los negocios no necesita la nube
- Algunos tienen una visión completamente desconectada de cómo es un negocio real de software
- Piensan desde una perspectiva Fortune 500 y creen que el estándar es enterprise
- Asumen que el negocio promedio necesita alta disponibilidad, replicación multizona, failover automático, clústeres distribuidos de Kubernetes y todo el paquete de la nube
- En la práctica, poquísimos negocios de software necesitan eso
- La mayoría de los negocios siempre será pequeña por una ley de potencia
- En Estados Unidos, las pequeñas empresas representan el 99.9% de todos los negocios
- En la Unión Europea, las SME (menos de 250 empleados) representan el 99% de los negocios
- La mayoría de los desarrolladores sobreestima las necesidades de escalado
- Su umbral de lo que consideran "alto tráfico" es demasiado bajo
- Como referencia, hoy manejan millones de requests al día para millones de visitantes mensuales con una configuración de solo 2 servidores
- Creadores indie como @levelsio corren todo en un solo servidor
- La mayoría de los desarrolladores nunca ha operado su propio proyecto con usuarios reales y tráfico de producción en un solo servidor
- También sobreestiman los requisitos técnicos
- Muy pocos negocios de software necesitan realmente esas capacidades, y normalmente tienen buenas razones técnicas para ello
- En el caso de Netflix: tiene que transcodificar y transmitir enormes volúmenes de video a clientes de todo el mundo, así que necesita sistemas distribuidos, CDN y edge computing
- Si tienes una app pequeña con mil usuarios que solo intercambia objetos JSON, eso no hace falta para nada
- Muchos desarrolladores tienen una idea casi mágica de que su proyecto es como Netflix
- Es pensamiento optimista, y se entiende, pero lleva a malas decisiones técnicas
- Creen que hace falta distribuir servidores por todo el mundo porque el usuario notará unos pocos milisegundos al tocar un botón
Los servidores van a estar bien
- Mucha gente tiene ideas casi mágicas sobre cómo funciona un centro de datos
- Piensan que los servidores dentro del datacenter son frágiles, volátiles o que pueden desaparecer en el aire
- Incluso hay gente que cree que un rayo podría derribar por completo un centro de datos
- Los datacenters modernos ya contemplan todos esos problemas y tienen muchas protecciones
- No solo contra cosas normales como los rayos, sino contra casi cualquier cosa que pueda amenazar el uptime
- Energía redundante, enfriamiento redundante, conexiones redundantes a internet, sistemas redundantes contra incendios, sistemas redundantes de seguridad y mucha seguridad física
- Todo en un centro de datos está diseñado con resiliencia y redundancia (al menos N+1, a veces 2N) para garantizar la disponibilidad
- La mayoría de estas opiniones vienen del miedo y del éxito del marketing y las campañas psyops de la nube
- ¿Dónde guarda AWS sus máquinas? ¿En un lugar mágico debajo de un arcoíris?
- ¿Cómo es que solo las máquinas de AWS estarían mágicamente protegidas de los mismos problemas que tienen otros datacenters?
- Claro que pueden ocurrir desastres (como el incendio de OVH en 2021), así que necesitas respaldos para recuperarte
- Pero en unos 15 años operando servidores, dice que eso es raro y que nunca ha sufrido más que unos cuantos minutos de downtime
Administrar servidores no es un trabajo de tiempo completo
- Quien ha administrado servidores durante suficiente tiempo sabe que la mayor parte del esfuerzo está en la configuración inicial, y que después los servidores son relativamente estables
- Las fallas de hardware son relativamente raras y, una vez que el servidor queda funcionando, normalmente puede seguir así durante años sin grandes intervenciones
- Administrar tus propios servidores no es un trabajo de tiempo completo
- No necesitas contratar un equipo de 5 personas de devops
- Tampoco necesitas contratar a alguien dedicado a servidores: puedes hacerlo tú mismo y no es tan difícil
- Claude y ChatGPT entienden bastante bien los sistemas Linux y cómo administrarlos, así que puedes pedirles ayuda
- Después de publicar el tuit, algunas personas asumieron que era la primera vez que operaba un servidor y que era demasiado optimista respecto a lo que eso implica
- Pero administra servidores desde 2006
- Empezó editando scripts PHP y subiéndose por FTP al servidor
- Aprendió a instalar WordPress, editar plantillas de WP, y a partir de ahí vino todo lo demás
- Fue una experiencia valiosa que le enseñó las bases
- Aprendió qué es Linux y cómo moverse dentro del sistema
- Para 2007 ya había pedido a Canonical CDs de Ubuntu por correo y los instaló particionando la computadora de sus padres para aprender Linux
- Esa experiencia temprana le dio los fundamentos del desarrollo web, y todo lo demás se construyó encima de eso
La importancia de aprender Linux
- La nueva generación de desarrolladores (Gen Z y Gen Alpha) está completamente desconectada del hardware donde corre el software
- Les falta este tipo de experiencia fundamental
- Nacieron en una época donde alguna persona random en YouTube promociona cierto proveedor y enseña a correr un comando que supuestamente resuelve mágicamente todos los problemas de infraestructura
- Es lógico que tengan supuestos casi mágicos sobre qué es un servidor y cómo funciona
- Dicen que pueden trabajar con "serverless", pero no se dan cuenta de que siguen ejecutando código en muchas otras cajas
- Claro, muchos sí terminan aprendiendo más sobre Linux y servidores, pero el egresado promedio de un bootcamp no tiene la experiencia práctica en Linux que sí tenían los hackers del FTP hace 20 años
- No hace un juicio moral sobre eso, no dice que sea bueno o malo: simplemente es el estado actual del desarrollo web
- El resultado es que empresas como Vercel monetizan a una nueva generación de desarrolladores que no entiende realmente lo que hace y nunca ha operado servidores por sí misma, ganando millones de dólares
- La ignorancia se paga dos veces: por la ignorancia en sí y por lo que otros cobran por aprovecharse de ella
- Si no entiendes cómo funcionan las cosas, eso realmente te cuesta dinero
Este es el mejor momento para aprender servidores
- Si nunca has administrado tus propios servidores y te asusta cualquier cosa que huela a backend, todo va a estar bien
- De hecho, nunca ha habido un mejor momento para aprender a manejar servidores
- Tanto Claude como ChatGPT saben muchísimo de Linux y pueden guiarte paso a paso de una forma sin precedentes en la historia tecnológica
- No solo puedes entender cómo configurar algo y cómo funciona, sino también hacer preguntas y seguir pasos cuando necesites cambiar algo, sin contratar a nadie
- No da tanto miedo, y tampoco hay que hacerlo tan seguido
- En una era de IA donde generar código ya es estándar y el código puede volverse una commodity, saber desplegar ese código en un servidor de producción barato y hacer que de verdad le sirva al usuario final puede convertirse en un diferenciador clave como desarrollador
- Sí, hay que preocuparse por temas como la seguridad
- Ignora a quien diga que operar tus propios servidores es menos seguro que operar servidores en AWS, como si una instancia EC2 estuviera mágicamente protegida de los hackers,
- En realidad configurarlo bien no es tan difícil, siempre que sigas guías y scripts de configuración
- Muchos desarrolladores con más experiencia trabajan mucho peor en producción que tú con ayuda de IA
- Si le preguntas a ChatGPT cómo endurecer un servidor Linux y cómo seguir buenas prácticas de seguridad (no usar autenticación por contraseña, usar solo claves SSH fuertes), ya llevas 90% del camino recorrido
- Cloudflare puede dar una capa adicional de protección
- Después de asegurar tu caja Linux, pon Cloudflare encima de todo
- Si en DNS haces proxy de la IP del servidor para que no quede expuesta, mejor todavía
- Obtienes protección contra DDoS, edge caching y DNS de primer nivel prácticamente gratis
24 comentarios
Si consideras el tiempo y el esfuerzo que implica construir por tu cuenta la infraestructura necesaria on-premises, no parece que los servicios en la nube sean tan caros.
Y los servicios en la nube se usan por la alta disponibilidad que ofrecen, no por el costo.
Creo que es como el concepto de IKEA o Daiso.
Seguro hay servicios cloud muy convenientes en costo y razonables.
Pero cuando empiezas a usarlos, terminas usando junto con ellos otras cosas que ya se ven un poco caras.
(Un ejemplo cualquiera) si usas Lambda, luego terminas usando API Gateway, y eso es algo caro e incómodo -_-^
Es algo así.
Por cierto, con lo que sí estoy muy de acuerdo es con esto.
Por qué AWS les resulta conveniente a estas personas
Porque se ve técnicamente complejo y hace que parezcas inteligente frente a otros desarrolladores
Esas frases.
La verdad, como los servicios de AWS llevan mucho tiempo y han ido evolucionando, hay varias funciones que ni siquiera han podido deprecar, y como saber bien de esas cosas se veía genial, yo también saqué la certificación SA jajaja... totalmente de acuerdo.
La nube, on-premises y los IDC tienen cada uno sus ventajas y desventajas, así que al final la clave es elegir según el propósito de uso y la escala.
La premisa más grande es que “las fallas de hardware casi no existen”, pero...
Por lo que me tocó vivir, cuando en la empresa alquilábamos un rack en un IDC y operábamos servidores, recuerdo que más o menos cada tres días se moría un disco, y andábamos cambiando discos y yendo a reconstruir el RAID...
Si se puede, yo les digo que simplemente usen la nube. Cuando se rompe el hardware, el valor de poder levantar todo de nuevo con un simple “clic” es enorme.....
Que un disco muera una vez cada 3 días sí está medio raro... No parece un caso normal.
Es una historia de hace más de 10 años, y probablemente era Seagate...
Backblaze anunció que el año pasado se averiaron 4372 unidades, así que a esa escala sí se les descompone más o menos un disco cada 2 horas...
Es una frecuencia que puede darse a una escala muy grande.
Bueno, trabajé bastante tiempo en un centro de cómputo de unas 100 racks 42U con un entorno que incluía HPC, HCI, un sistema de archivos distribuido armado con Hadoop de los primeros tiempos y todo tipo de almacenamiento, pero nunca vi que se dañara un disco cada tres días.
Opinión de Hacker News
Llevo años administrando mis propios servidores y, al mantener todo simple, he ahorrado mucho tiempo y dinero
Evito AWS y Azure porque su configuración es compleja y su UI tampoco me convence
Lo importante es gestionar el servidor de modo que pueda recrearse solo con archivos de configuración en cualquier momento. Por eso herramientas como Ansible son esenciales
Si de verdad tienes que usar la nube, recomiendo DigitalOcean. Es simple e intuitivo, y eso ayuda a mantener la salud mental
Yo uso DO solo para recuperación ante desastres de nivel 3, y automatizo la configuración del clúster con Terraform y Ansible
La mayoría de las comunidades de desarrollo tienden a dejarse llevar por las modas, pero yo, incluso en ese ambiente, despliego un monolito de Clojure sobre la JVM en mi clúster de servidores físicos y genero ingresos estables
configuración de
ulimit, problemas de rendimiento con SYN cookies, actualizaciones de seguridad, respuesta ante ataques de día cero, envío de correos (calentamiento de IP, gestión de listas de spam), cumplimiento de GDPR, etc.Todo eso pasa a ser mi responsabilidad, y quienes usan la nube no son simplemente personas “engañadas”
No me gusta el pensamiento en blanco y negro. La mayoría de las startups ahorraría bastante si se cambiara de EC2 a lugares como Hetzner, Linode o DigitalOcean
Pero la nube también tiene muchas ventajas: funciones como backups, DB administradas y múltiples AZ se pueden usar con unos cuantos clics
No hay inversión inicial en hardware y, si tienes picos de carga grandes, incluso puede salir más barata
Aun así, como el tiempo de ingeniería vale mucho, la nube puede ser una decisión razonable en etapas de crecimiento acelerado
Al final, la nube no es cara por sí misma, sino porque se usan funciones innecesarias
Hay muchos casos donde una estrategia multicloud evitó desastres
Los VPS o servidores dedicados también casi no tienen costo inicial, y salvo que la carga pico sea realmente extrema, la nube no necesariamente sale más barata
Las DB administradas son cómodas, pero hay demasiadas actualizaciones forzadas; si no estás a gran escala, me parece mejor administrarlas tú mismo
Antes escalar hardware era difícil, pero ahora incluso un solo servidor puede rendir como racks enteros de antes
Los proyectos medianos ahora pueden resolver por su cuenta problemas que antes resolvía la nube
Eso sí, para conseguir soporte de personal externo, la nube es muchísimo más fácil, mientras que para self-hosting es difícil encontrar gente de soporte
Yo personalmente prefiero el self-hosting, pero para quienes no quieren tocar la infraestructura por su cuenta, creo que la nube es mejor
Antes llevaba IT en una startup de hedge fund
Corríamos programas de análisis en C++ sobre un servidor dual Xeon (512GB RAM), pero el jefe se puso nervioso después de que, en un almuerzo, le preguntaran “¿por qué no usan AWS?”
Vi una realidad donde el “cumplimiento de buzzwords” se valora más que la eficiencia
Muchos CTO gastan presupuestos innecesariamente grandes por este ambiente, y vivimos en un mundo donde una arquitectura eficiente incluso puede convertirse en una desventaja de marketing
La expresión “ahorrar 10x” es lógicamente incorrecta. 10x significa más, no menos
El costo de la mano de obra de mantenimiento es mayor que el de los servidores
Incluso si operas 10 instancias EC2, puedes automatizar los parches con Systems Manager, así que no necesitas construir tu propia automatización
El debate sobre la nube no es blanco o negro
En pequeña escala, Hetzner o AWS son parecidos, y en grandes empresas la clave es si puedes construir tu propio tooling
El tramo de las empresas medianas (SME) es el más ambiguo. Si necesitas sistemas totalmente aislados por cliente, AWS conviene; si tienes carga constante 24/7, tus propios servidores son mejores
Si usas la nube solo para hosting de VM, sales perdiendo. Muchas veces pagas el costo sin usar las funciones de la nube
Con servidores propios tienes que pagar la capacidad máxima todo el mes, mientras que en la nube pagas solo por los días que la necesitas
La nube es muy útil para construir un MVP y validar el mercado
Puedes experimentar rápido con créditos para startups y free tiers, y si luego el costo se vuelve un problema, te cambias
Eso sí, desde el inicio debes diseñar una arquitectura independiente del servidor, y conseguir tiempo para la migración no es fácil
Nuestro equipo usa Google Cloud, pero gastamos tan poco que el ejecutivo comercial está molesto
La posibilidad de moverse entre nubes funciona como poder de negociación
Además, la nube facilita responder a SLA o normativas de protección de datos, lo que ayuda a ganar la confianza de clientes empresariales
Me intriga por qué AWS creció de forma tan explosiva al principio
A comienzos de los 2010, alquilar racks y montar servidores era caro y lento, y una configuración multirregión era casi imposible
AWS resolvió esos problemas, pero ahora la situación cambió
También estaba la anécdota de Squarespace, que durante el huracán Sandy llevó combustible por su cuenta para mantener vivos sus servidores
Puedes pedir un servidor en Hetzner y, 10 minutos después, tener Ubuntu instalado y la configuración de Ansible lista
Tarifa fija, ancho de banda ilimitado, rendimiento predecible: atrae esa simplicidad sin abstracciones innecesarias
EC2 eliminó esa incomodidad, y Lambda fue un paso más allá. Ahora el alquiler de bare metal es mucho más barato
La política de créditos gratis de AWS en el pasado era, en la práctica, una estrategia de lock-in
Poner tus propios servidores en un datacenter no es tan difícil como parece
Yo necesitaba CPUs de alta frecuencia para un servidor de gaming, y como eran difíciles de conseguir en la nube, monté mi propia infraestructura
Lo operé por unas £15 al mes incluyendo la instalación, funcionó bien durante años y, al final, el ahorro fue grande
Teníamos equipos en un datacenter de Seattle y hacíamos administración remota con KVM basado en módem
Nosotros migramos a Hetzner hace unos años y, gracias a lo que ahorramos, parece poco probable que volvamos a la nube
La excepción son Cloudflare Workers, cuya calidad es buena y cuyo cupo gratuito es generoso
Gracias a la IA, ahora es mucho más fácil escribir scripts de automatización, despliegue y backups, así que administrarlo es más simple que antes
Como referencia, Claude Code de Anthropic está ofreciendo $250 en créditos gratis para usuarios Pro/Max hasta el 18 de noviembre
El anuncio relacionado se puede ver en este tuit
¿No sentirías su valor con solo experimentar una restauración de respaldo una vez? En on-premise, la restauración de respaldos es lo más complicado.
Bueno... estoy de acuerdo al cien por ciento con que "los costos de la nube son más caros de lo necesario" y que "en la mayoría de los casos no se necesitan las funciones de las grandes nubes", pero el tono del texto hace incómodo leerlo, como si estuviera afirmando que todos los servicios en la nube son una estafa. Suena como decir: "todos los seguros son una estafa".
La nube se usa cuando no quieres administrar servidores o cuando la demanda no es fácil de predecir y necesitas escalar rápido. Fuera de esos casos, no sé si tenga mucho sentido.
Estoy de acuerdo con todo, pero me parece una lástima que no haya una explicación desde la perspectiva de la seguridad cuando uno opera servidores directamente durante años.
Yo también quisiera apoyar esta opinión.
Así es.
Estoy 100% de acuerdo en que la nube es cara.
Pero si pienso que ahora mismo habría que configurar y usar directamente Kubernetes sobre bare metal para más de 200 contenedores,
siendo un desarrollador backend en solitario y sin devops, considerando que por la mitad de la mitad del costo del salario de una persona se reduce la carga de administrar y operar los servidores, la verdad es que tampoco es una mala opción.
Si hubiera personal dedicado "solo" a gestionar la infraestructura de servidores, salir de la nube sin duda podría ser una buena opción.
En lo personal, al intentar construir un servicio excluyendo la nube lo más posible, casi me vuelvo loco.
Necesitaba un registro de imágenes de contenedores, pero al intentar montarlo, el almacenamiento local era una carga, así que empecé a revisar opciones compatibles con S3 por la facilidad de los respaldos, levanté también un servicio de VPN para bloquear el acceso externo, y además tuve que encargarme de la gestión de certificados HTTPS en el reverse proxy y de varias configuraciones de seguridad para CI/CD... autohospedarlo uno mismo...
Si solo vas a usar unos pocos servicios simples, entonces por supuesto que bare metal sale más barato y probablemente esa sea la forma correcta de hacerlo. Pero si necesitas integrarlo con otros servicios y quieres quitarte de encima varias de esas cargas, aunque el costo del servidor sea más caro en este momento, puede que termine siendo conveniente porque te ahorras el costo de instalación y administración al no tener que montar uno por uno todos esos servicios.
Hay muchos repositorios de imágenes de código abierto.
Sí, hay muchos. Me refería a la carga de tener que operarlo directamente. Yo también uso Nexus o Harbor.
En mi experiencia personal no hubo carga ni problemas.
Como el criterio de lo que se considera una carga puede variar entre personas, supongo que también puede parecer así.
¿Qué tipo de servicio están desarrollando que necesitan un registro de imágenes de contenedores?
Se debe a que, sin importar qué servicio desarrolle, prefiero desplegarlo en contenedores. También prefiero hacer los despliegues, en lo posible, sin conectarme directamente por
ssh. Si solo se piensa en el costo... supongo que puede haber formas de desplegar directamente sin un registro, pero lo mencioné como ejemplo, y quiero centrarme en las partes algo incómodas que surgen, como los servicios de correo electrónico.