La característica principal de cualquier negocio de SaaS es la reducción masiva de los costos operativos y la complejidad, incluida la instalación, la configuración, el mantenimiento continuo y las actualizaciones. Dado el éxito arrollador del SaaS en las últimas décadas, podemos ver claramente que, para muchos clientes, utilizar un modelo de SaaS en lugar del software tradicional empaquetado ha tenido mucho sentido desde el punto de vista financiero. Esto concuerda con una teoría que afirma que hay un nivel constante de complejidad en un sistema en un momento dado; las organizaciones de TI pueden hacer frente a esto invirtiendo internamente (invirtiendo en un equipo que gestione la complejidad) o subcontratando a un socio o proveedor de SaaS/PaaS/IaaS (intercambiando dinero por complejidad). Cuando se combina este último con un modelo financiero de OpEx en lugar de CapEx, una instalación y configuración sencillas y opciones flexibles de pago a medida que crece, resulta muy difícil justificar cualquier otro modelo de entrega de software genérico.
Las empresas de SaaS, por otro lado, rentabilizan este modelo al distribuir los costos operativos de funcionamiento entre muchos clientes utilizando (casi siempre) un modelo basado en suscripciones. Si bien los modelos de entrega de software heredados comparten el mismo principio de distribución de costos a nivel de I+D, carecen de la capacidad de arbitrar el costo operativo a nivel de entrega: es costoso entregar un software seguro, de alta disponibilidad y continuamente actualizado a escala, y se necesita un equipo capacitado de desarrolladores y operadores para entregar el software dentro de los límites del SLA definidos por el cliente, a lo largo del tiempo.
Dado que una gran parte del costo del desarrollo y la entrega de SaaS se destina a crear la infraestructura sólida y segura necesaria para alojar el servicio, los proveedores ganan dinero creando y dividiendo una infraestructura grande y sólida en partes más pequeñas de la misma calidad, y venden esas piezas a muchos clientes. La infraestructura SaaS suele constar de muchos componentes, desde bases de datos hasta balanceadores de carga, cada uno configurado específicamente para prestar el servicio de una manera particular, con requisitos de alta disponibilidad (HA), redundancia y seguridad a nivel de componentes. Piense en un SaaS de CRM típico: necesitará un servidor de bases de datos replicado en varias zonas, un grupo de servidores frontend con equilibrio de carga y firewalls seguros y un clúster de servidores para encargarse de los trabajos en segundo plano y del mantenimiento del sistema. **** Por ejemplo, para conservar los detalles de sus 2000 clientes, necesitará unos 12 servidores, dos balanceadores de carga y varios gigabytes de almacenamiento; además de eso, añada el costo del equipo de operaciones de mantener esas bases de datos y servidores: todo esto probablemente represente un costo de 20 000 dólares al mes solo para ponerse en marcha. Para empeorar las cosas, incluso con esta inversión, no se acercará al tiempo de actividad de cinco a nueve (99,999%) que un proveedor de SaaS le ofrecerá por una fracción del precio. En este escenario, tiene mucho sentido optar por una alternativa de SaaS y pagar 2000$ al mes por un servicio que siempre está activo, actualizado y respaldado. ## Sin embargo,
esto podría cambiarPara ver por qué, vale la pena entender por qué es tan caro administrar una infraestructura robusta, segura y de alta disponibilidad. En lo que respecta a la infraestructura, «la cadena es tan fuerte como su eslabón más débil». La alta disponibilidad y la seguridad no se pueden lograr solo haciendo que las partes del sistema sean altamente disponibles y seguras; esto debe hacerse en todos y cada uno de los componentes, lo que aumenta el costo y la complejidad, lo que aumenta aún más la factura
.Ahora, plantéese si todos esos requisitos estuvieran integrados en una infraestructura genérica, con capacidad de recuperación automática y a gran escala, de modo que cualquier aplicación que se ejecutara sobre ella fuera intrínsecamente altamente disponible, redundante y segura. Esta es la promesa de los contenedores. En lugar de dedicar tiempo a la prestación de cada servicio con un SLA elevado, la infraestructura se encarga de ello en el nivel inferior y proporciona estos atributos como un servicio al usuario. De este modo, los contenedores se llevan una de las mayores ventajas del modelo de entrega de SaaS: el arbitraje de infraestructura, que definí anteriormente en
el post.Los sistemas de infraestructura basados en contenedores, como Kubernetes, permiten a las empresas de cualquier tamaño crear su propia infraestructura sólida, personalizada y de alta disponibilidad sobre centros de datos privados o nubes públicas, con una gran granularidad y flexibilidad, sin comprometer mucho a cambio. En este nuevo mundo de infraestructuras basadas en contenedores, los equipos de TI dedican su tiempo a crear y mantener algunos clústeres de Kubernetes, mientras que los proveedores externos y los desarrolladores internos utilizan esos clústeres para prestar
servicios a sus clientes.Probablemente pasarán años hasta que este cambio afecte a la industria del SaaS de manera significativa. Sin embargo, si analizamos con atención, ya podemos ver a equipos de TI expertos que buscan impulsar este futuro: creando canales para su código, así como sistemas de administración de aplicaciones que permitan automatizar la infraestructura en contenedores, tanto en la nube pública como en
la privada.El modelo de entrega de software como servicio (SaaS) todavía tiene muchas ventajas a su favor. Por un lado, ahora es el modelo dominante para consumir software, esté donde esté o sea cual sea el proveedor. Sin embargo, el arbitraje de infraestructuras no va a ser una de sus principales ventajas durante mucho tiempo. Si bien la computación en nube fue la mejor aplicación para la virtualización, cambiar la economía del SaaS podría ser la mejor aplicación para la contenedorización
.