Llevamos unos días en mi trabajo del Mundo Real™ evaluando opciones para renovar nuestras añejas herramientas de desarrollo, basadas en Subversion como VCS y Cruise Control.NET como servidor de integración, y tratar de mejorar algunos procesos.
Quiza lo más razonable dados los tiempos que corren sería plantearse una solución basada en servicios en la nube, pero después de analizarlo, podríamos resumir nuestras conclusiones en el título de este post: la nube es para pobres.
(El mérito de esa frase tan link baitter es de Luis Sánchez a quien le agradezco que me haya dejado usarla en este post.)
Si te lo puedes permitir, no usas la nube
¿Os imaginais a un jeque de esos que van quemando billetes en Marbella alquilando un coche (Platform as a Service) o cogiendo un taxi (Software as a Service)? No. Ellos tienen su propio Bentley con chófer on premises, siempre disponibles para ellos, sin necesidad de depender de nada externo.
Vale, seguramente este tipo de personas no sean el mejor ejemplo de racionalización de costes, pero lo cierto es que disponer de recursos propios te garantiza una independencia y control que no son fáciles de conseguir con soluciones en la nube.
Precisamente en las últimas dos semanas se ha anunciado el cierre de dos servicios de almacenamiento de código fuente, Codehaus y Google Code. En el caso de Google Code hay herramientas para migrar los proyectos a otras plataformas, pero no deja de ser un inconveniente tener que hacerlo y adaptar todos los procesos que puedas tener integrados con Google Code para que ahora se integren con GitHub o BitBucket.
Para mi éste es el mayor hándicap a la hora de optar por una solución en la nube: adquieres una dependencia sobre un proveedor externo.
Esta dependencia es mayor cuando se trata de una solución basada en Softare as a Service o incluso en Platform as a Service. Cuando utilizas Infrastructure as a Service tienes algo más de flexibilidad porque al final estás usando máquinas virtuales que, teóricamente son más fáciles de mover entre distintos proveedores.
Depender de un proveedor de servicios implica que cuando su modelo de negocio deje de ser rentable, tendrás problemas. Que cuando decidan descontinuar la versión que estás utilizando, tendrás que adaptarte. Que las paradas técnicas de manteniento (que no debería haberlas, pero las hay) las elegirá el proveedor y no tú.
Todo esto se puede mitigar si eres el dueño de tu infraestructura. En ese caso, tú decides hasta cuándo mantenerla, cuándo actualizarla o en qué momentos programar las operaciones de mantenimiento que implican una caída de servicio.
La parte mala, claro, es que esto no es barato. Necesitas comprar hardware, licencias de software y contratar (ya sea interna o externamente) recursos para la instalación y mantenimiento del sistema. Pero si te lo puedes permitir, es la opción más segura.
Entonces, ¿la nube es un timo?
No, ni mucho menos. Igual que un taxi nos permite a los que no tenemos chófer o vehículo propio disponer de un servicio para desplazarnos, la nube permite que los que no podemos afrontar tener datacenters por todo el mundo obtengamos redundancia geográfica y podamos servir el contenido más rápido a usuarios dispersos por el mundo.
Gracias a la nube podemos utilizar un sistema de facturación sin necesidad de saber instalarlo, podemos desplegar aplicaciones en servidores web perfectamente configurados sin que sepamos casi ni su nombre o disponer de potencia de computación en momentos puntuales que no amortizaríamos ni en una década si tuviésemos que comprar el hardware físicamente.
La nube hace accesibles tecnologías que antes estaban sólo al alcance de los más grandes.
Si en lugar de trabajar en una empresa que ya tiene una infraestructura de servidores estuviese trabajando por mi cuenta, gracias a servicios en la nube podría montar mi servidor de control de versiones y mi servidor de integración, cosa que no podría permitirme hacerlo por mi cuenta.
Por supuesto, tendría los riesgos de los que hablaba antes, pero al menos tendría una opción más sólida que montar un PC debajo de la mesa del salón y rezar porque no le pasase nada.
Además, aprovechar las posibilidades de la nube permite tener una mayor flexibilidad a la hora de dimensionar y cambiar los servicios y recursos que empleamos. Si tienes que invertir 3 semanas en desplegar una nueva aplicación en tus servidores locales es probable que dejes pasar oportunidades de mejora por ahorrarte ese esfuerzo, pero si hacerlo a través de proveedores de servicios resulta simple, podrás evolucionar tus soluciones de forma mucho más ágil.
Cuando la nube sí que se convierte un poco en un timo una opción discutible es cuando nos intentan vender soluciones ultracomplejas basadas en un cluster con cuatro redis, un ESB, dos SQL Servers y un MongoDB para montar un sistema de facturación para 30 usuarios.
Antes era impensable hacer eso por los costes que implicaba, pero ahora, como la nube los «abarata», se oferta. La realidad es que en esos casos, si comparas el coste de la nube con el coste de una solución sensata, instalada en un servidor local (o en un hosting/housing si quieres más seguridad), al final sale más rentable huir de la nube. Pero esa es otra historia y la culpa no es de la nube.
Conclusiones
Aprovechando los servicios en la nube podemos tener acceso a tecnologías y arquitecturas muy interesantes, pero estamos introduciendo una dependencia más o menos fuerte sobre proveedores externos.
La gravedad de esta dependencia depende de la importancia que tenga para tu negocio lo que estés poniendo en la nube. No es lo mismo poner una web con información corporativa, que un sitio de comercio electrónico, que un sistema de producción como es, en nuestro caso, el control de código o el servidor de integración.
Si te lo puedes permitir, optar por soluciones on premises te da el máximo control sobre tus aplicaciones y a medio plazo puede incluso suponer un ahorro de costes (de forma similar a lo que ocurre al comprar una casa en lugar de alquilarla), pero los costes iniciales, y no sólo me refiero al aspecto puramente monetario, son indudablemente mayores.
Al final, igual que pasa con el código, la plataforma, nube o no, importa, pero el contexto más.
No puedo discrepar más.
Si te sale (como al de Marbella) el dinero por las orejas, si usas una tecnología (servicio) poco robusta, será porque ni el dinero te ofrece otras alternativas (ej. a Elon Musk le gusta la gaseosa); pero no es el caso, habiéndolas como ocurre con el tema que comentas, la nube, (ej. Amazon, Azure) la probabilidad de que te quedes en bragas es muy muy inferior (ej) a una caída de red eléctrica en tu datacenter.
Tener una infraestructura propia cuando hay gente que se dedica a eso y saliéndote el dinero por las orejas no tiene, literalmente, ningún sentido.
¿Siendo tu objetivo principal X cosa vas a competir en calidad, robustez e infraestructura con Amazon, Microsoft, Google, …? *NO*
Es justo lo contrario, si eres pobre, sabes que tendrás que trabajar más, que tendrás que mantener equipos obsoletos (que te gustaría tirar a la basura y comprar otros nuevos), que te arriesgarás a una caída de red eléctrica, mirar el RAID de tus discos rezando para tener un repuesto en condiciones (porque sino tendrás que comprar otra máquina o balancear removiendo tu tinglado), liándote la manta a la cabeza para mantener gigas y gigas en copias de seguridad, balanceando cargas, etc… porque, si eres rico, te vas a EC2 o Azure, pagas una pasta y te olvidas literalmente de todo eso y no tendrás nunca problemas ni de ancho de banda, ni de rendimiento, ni de nada, porque pagando lo necesario lo tienes.
¿Que necesitas otra máquina? pues otra instancia y punto, ¿que baja el rendimiento? pues escalas horizontalmente y punto, ¿copias de seguridad? ¡las hacen ellos! etc…
Sinceramente, tener que mantener tu propia infraestructura (yo lo hago) es de pobres, porque es muchísimo más barato que cualquier solución actual en la nube, pero requiere un esfuerzo *Y RIESGO* adicional que contratando servicios especializados no tienes.
Quizás no he entendido algo pero vamos hombre, me vas a comparar…
PD: me he enfocado en la infraestructura general pero en cuanto a repositorios, integración continua, etc… también hay proveedores muy robustos y muy buenos que no merece la pena intentar emular, salvo que seas pobre…
Pues yo creo que el anterior comentario y el post no discrepan «tanto». Yo, buscando soluciones cost-effective, tengo claro que hay servicios que me interesa tener en la nube, otros on-premise, y otros mixtos.
Si en mi empresa sobrara el dinero, probablemente lo tendría todo en la nube, tendría conexiones a internet redundantes de alta calidad (porque no se donde estáis vosotros, pero por donde yo me muevo, tener una conexión a internet fiable y con buena velocidad de subida es más dificil -o caro- que servidores redundantes y el sueldo de alguien que los administre).
Mi empresa tiene necesidades bastante básicas, por lo que en muchas ocasiones, la nube es un problema más que una solución… tenemos un par de servidores relativamente baratos con VMs separadas por «servicios», con RAID, y nos vale… incluso podemos permitirnos no tener ni hot-swap para el RAID… el downtime de un fallo de un disco duro (o placa base, o cualquier cosa) para cambiarlo y reconstruir el RAID es permisible.
Probablemente el coste de la nube para lo que nosotros usamos fuera el mismo o más, y la administración de esos servidores es bastante baja en general… y sin embargo, estaríamos limitados (al menos en la localización geográfica en la que estamos) por una conexión a internet de calidad y fiable, que no tenemos (de bajada «sobra», pero ahora mismo, a precio razonable, nos es CARISIMO pasar de las 512kbps de subida).
Yo entiendo que cada caso es diferente, y hay que valorar todo… hasta ahora para mí, tener las bases de datos en la nube, por el tema de la velocidad y fiabilidad de internet, nos era TOTALMENTE impensable… la velocidad de acceso del ERP sería -horrenda-, ahora vamos a cambiarnos de localización a otras oficinas donde podremos tener conexión bastante fiable, con varias mbps de subida (y chorrocientas de bajada) a un precio más que razonable, y es posible que pase los servicios con menos uso de CPU a Azure o similar, aunque sea por quitarme las tareas de administración de servidores (a las que, por el tamaño de la empresa, me toca dedicarme a mi personalmente ahora, sin yo ser un especialista en ello, ni ser precisamente un trabajo que me apasione).
Lo dicho, cuestión de equilibrar… al igual que el título del blog, «los servicios importan, pero el contexto más»
Gracias por vuestros comentarios, me alegra ver que hay diversidad de opiniones.
Jose Juan, no creo que lo que dices esté tan alejado de lo que comento en el post.
Cuando dices que en la nube «pagando lo necesario, lo tienes», eso mismo es aplicable a la infraestructura propia, no hay por qué estar manteniendo un equipo antiguo cruzando los dedos para que aguanten los raids, pagas lo necesario y te compras uno nuevo más rápido y más bonito, y tus ingenieros de sistemas de élite te lo montan y te lo mantienen perfectamente funcionando para ti.
Lo que pasa es que es más caro comprarte un equipo nuevo (y tirar lo que te gastaste en el anterior) que cambiar la instancia de Azure. Lo mismo pasa con los backups, la redundancia de las líneas y todo lo demás (incluidos los ingenieros de élite superlistos que te mantienen todo). Puedes tenerlo tú, pero es mucho más caro que dejar que alguien que se dedica masivamente a eso (Google, Microsoft o Amazon) te lo revenda.
La segunda parte del post pretendía dar argumentos en esa línea a favor de la nube.
¡Que titulo más interesante y más cierto! ¡la nube te reduce, en muchos, muchísimos casos, los costos! pero no conozco la primera compañía (por lo menos no aquí) que este dispuesta a «derrochar» dinero como el jeque de tu ejemplo :P la gran mayoría exprime cada centavo esperando un retorno de inversión bien poderoso :33
Por eso estoy en desacuerdo con mantener tu infraestructura on premise, aunque como siempre: depende :P. Hay que ver casos como el de Stack Exchange y su grupo de gurus que han sabido afinar tanto sus maquinas que no confían en que un proveedor de PaaS pueda llegar a tal punto de optimización. Pero para una gran mayoría de compañías y sectores del mercado con picos predecibles e impredecibles la elasticidad que da la nube es un plus poderoso (y esto hablando solo de escalabilidad)! gana muy poco una tienda online que deba invertir n mil dolares en un servidor solo para soportar las ventas navideñas y que se subutilice los otros 11 meses del año.
Aunque lo que dices de tener la dependencia con el proveedor es cierto!! hay que ver casos como el de Microsoft Azure y su cambio a Azure Redis Cache… donde el anterior servicio iba a ser descontinuado. Y pese al gran lapso que hubo aún hay gente que no se ha movido :S. Pero si tienes un proveedor serio de nube, y, donde dado el caso haya un cambio o des continuación de un servicio, verás que no es un simple: «Cortamos el servicio mañana, gracias por usarlo». No, es con mucho tiempo de anticipación, diseñan estrategias de mitigación y herramientas de migración, facilitan toda la documentación y diseñan todo el proceso para que sea lo menos costoso posible. Al final ellos deben mantener un SLA contigo.
Hola Nicolas,
Creo que todos coincidimos en que usando la nube te ahorras cosas, y el ejemplo que pones de elasticidad es un caso claro. De ahí mi exageración con el ejemplo del jeque, si te sobra el dinero, puedes permitirte tener un servidor parado 11 meses sólo para la campaña navideña y no depender de nadie.
Para mi ese es el punto clave, la dependencia.
Dices que los cortes de servicio no son inmediatos y que hay SLAs que cumplir, y es totalmente cierto, pero eso no quita que sean un fastidio. Por seguir con tu ejemplo, si yo tenía una aplicación felizmente en producción con Managed Cache, ahora tengo necesariamente que hacer modificaciones sobre ella (tengo un amplio periodo de tiempo, eso sí) para migrarla a Redis Cache antes de que se descontinúe.
Yo no gano nada con esa migración y el único motivo de hacerla es satisfacer el modelo de negocio de un proveedor externo.
Juan, estamos lejísimos y si tu dices (como dices) que quien se compra un Porche es pobre porque no se puede construir su propio utilitario de lujo pues me parece un sinsentido (por ser suave).
Un snob mantiene, pagando precios desorbitados, hardware desaprovechado y personal altamente cualificado (también desaprovechado) donde otros con pasta pagan un buen precio (pero razonable) por un buen servicio externalizado y donde los pobres no acuden para sacar algo más de margen.
Así, llamemos snob al snob, pudiente al pudiente y pobre al pobre.
Quien diga que teniendo pasta prefiere tener su hardware y personal es que no tiene pasta (ergo es pobre, que es lo contrario de lo que dices). Y si quieres un buen ejemplo mira a ver los comentarios de los responsables del ecosistema stackoverflow, que en la nube su hardware les saldría mucho más caro.
José Juan, no estamos comparando comprar un Porsche y construirse un utilitario de lujo, sino comprar un Porsche o alquilarlo.
Si te gustan los Porsches y te lo puedes permitir, te lo compras y no dependes de que la empresa de alquiler siga teniendo para alquilar el modelo de Porsche que te gusta.
De hecho, no estaríamos hablando ni de comprar o alquilar… estaríamos hablando de comprar o «tener a alguien que te recoja en el Porsche cuando lo llames»… porque si lo alquilar, lo tienes tu y tienen que venir a quitartelo… pero si es un servicio en el que llamas para que te recojan, mañana te pueden decir que «no tienen el Porsche y te tienen que recoger en un Renault» :-)
Los ejemplos de dependencias por usar la nube suenan a los que tienes por utilizar cualquier librería o framework de terceros, y aun así nadie (o casi nadie) se construye su propio fw MVC, su propio ORM, etc. Y no hacerlo no es de pobres, sino de inteligentes, por no reinventar la rueda y para peor…
Hola Javier,
Lo que planteas es otro caso de dependencias que también tienen su riesgo y uno debería valorar antes de asumirlas o no, aunque en el caso de librerías y frameworks hay una diferencia.
La gran mayoría no suponen un pago por servicio o suscripción, por lo que una vez que tienes tu DLL de NHibernate, te la puedes quedar para siempre, independientemente de lo que le pase a su creador/proveedor. En el caso de la Cache de Azure que mencionaba antes Nicolás no tienes esa flexiblidad, por lo que el riesgo que asumes es mayor.
Buen tema, yo estoy trabajando para un gran diario de mi país que hace 10 años había llevado sus servidores web a «la nube» (que en esa época no se llamaba así) pero hace 5 que lo volvió a traer a sus datacenters. ¿Porque? La flexibilidad: al tener requerimientos específicos su proveedor tardaba mucho en implementarlos cosa que teniendo los fierros «en casa» no sucede.
¿Como va la historia hoy por hoy? Buscando reducción de costos están evaluando llevarse de nuevo los servidores a la nube, evaluando tecnologías y procesos para mitigar la falta de flexibilidad …. por esto comparto totalmente el título de la entrada: la nube es para los pobres.
Pablo, hoy día, a menos que tengas requisitos de -hardware- específicos, puedes montar VMs totalmente funcionales en la nube y pagar por la CPU que usas… la diferencia es que el «hierro» lo tienen ellos en lugar de tú en tus oficinas (con la gran ventaja que eso supone).
Para mí, excepto para servicios específicos, sería la solución ideal, ya que en tanto que las VMs sean compatibles o migrables, que un servidor deje de funcionar es cuestión de cogerte la VM, y llevartela a otro.
Cuando hablamos de SaaS entonces sí que dependes de que el servicio en cuestión sea compatible, pero en el caso de VMs… creo que todos los proveedores de servicios de VM usan tipos de VM estándar (o las han convertido en estándar, como AWS)… migrar una VM de Azure a AWS, o Google Cloud Storage, o incluso a un VMWare ESX on-premises si se da el caso que se necesite, no es difícil ni lento.
Javier es como comentas, son necesidades particulares que no se resuelven con máquinas virtuales.
Están creciendo los requerimientos y acompañar ese crecimiento implica $$$ en fierros y personal … cosa que hoy por hoy no van a pagar y por eso evalúan nuevamente la nube. Y por esa razón también mi comentario de que coincide el título de que la nube es para los pobres….porque si los $$ estuvieran disponibles se compran más fierros y se contrata más personal.
Me recuerda a cuando las máquinas de escribir se quedaron obsoletas y había gente que ponía pegas. A cuando salió el automóvil y los que vivían de los caballos ponían pegas. A cuando salió la electricidad y los que vendían aceites y antorchas pusieron pegas.
La nube es el futuro, no es para pobres, es para los que quieren ser más ricos. Ahorra costes y delega la seguridad a empresas especializadas. Azure, Dropbox, Dataprius, Drive, Mega,…. en fin, hay montones. Algunos basados en sincronizar, otros centralizados.
La nube ha llegado para quedarse.
En mi empresa utilizamos Dataprius y va muy bien. Comparto la opinión de José. Con la nube hemos ganado en eficiencia, rapidez y agilidad a la hora de crear, trabajar y almacenar los documentos. Eso no es para pobres, es para aquellos que quieren progresar. Saludos.