Lo que SaaS nos enseña sobre la automatización de la infraestructura de red

El éxito de SaaS se debe en gran medida a que las empresas pueden identificar y encapsular en software procesos de negocio mercantilizados. Lo mismo ocurre con los equipos de redes e infraestructura dentro de la empresa.

SaaS (Software as a Service) es el mayor de los mercados de “nube” en la actualidad. A pesar del entusiasmo en torno a IaaS (como AWS, Azure y Google Cloud), la realidad es que SaaS ha superado ampliamente todas las demás formas de “nube” en términos de tasas de adopción y crecimiento continuo.

Y no ha mostrado señales de detenerse. Una encuesta realizada a principios de 2016 ilustró esta continua explosión de SaaS: los encuestados informaron que el número de aplicaciones SaaS oficialmente respaldadas por TI creció un 50 % en solo un año, pasando de 8 en 2015 a 12 en 2016. El informe predice que ese número volverá a crecer y llegará a 17 en 2017.

Teniendo en cuenta que el término “nube” ya tiene diez años, se trata de unas tasas de adopción bastante impresionantes para lo que tradicionalmente se consideran aplicações bastante estándar. Hablamos de CRM, ERP, CMS, suites ofimáticas relacionadas con la productividad y sitios para compartir archivos.

Probablemente te estés preguntando qué tiene que ver SaaS con la automatización de la infraestructura. Al fin y al cabo, son manzanas y filetes. Automatizar el aprovisionamiento y el escalamiento en la red no tiene nada que ver con SaaS.

Excepto que en cierto modo lo es. Tenme paciencia un momento, te lo explicaré.

Mira, uno de los temas comunes que atraviesan todas las aplicações SaaS es la mercantilización de la función. Arrastrar y soltar para compartir archivos es un paradigma bastante bien comprendido para compartir archivos, ya sea en el escritorio utilizando carpetas compartidas en la red o utilizando una interfaz basada en navegador. Lo mismo ocurre con los documentos y las presentaciones, e incluso con la publicación de contenidos. Hay un proceso bastante bien definido que define cómo uno hace X o Y, y si la interfaz es un navegador web o una aplicación independiente realmente no cambia el proceso, solo los íconos y la interfaz.

Muchas funciones empresariales también están altamente estandarizadas (mercantilizadas). El proceso que sigue un representante de servicio al cliente (CSR) después de responder a su llamada muy importante (y realmente lo es, todos nos aseguran que lo es) es probablemente el mismo independientemente de con quién esté interactuando. Llamar a la compañía de cable o a una empresa minorista para realizar un pedido le brinda una experiencia bastante estandarizada. Pero no se fíe sólo de mi palabra, aquí tiene un excelente artículo de Harvard Business Review (de 2005) que analiza esta misma convergencia en la estandarización de procesos que, poco después, conduciría al fenómeno hoy conocido como “SaaS”.

Una vez que cualquier proceso se estandariza (se convierte en un producto básico), resulta bastante fácil codificarlo y ponerle una interfaz que pueda venderse. Y yo diría que fue la mercantilización subyacente de esas funciones comerciales lo que ayudó a impulsar a los primeros proveedores de SaaS al estrellato. Con un modelo de datos y una interfaz básicos, fue bastante fácil proporcionar la personalización mínima requerida por los clientes para que el proceso coincidiera con sus necesidades. Listo. Éxito instantáneo.

Ahora apliquemos esto a la infraestructura y la red. Hay bastantes procesos relacionados con el aprovisionamiento, la administración y la escala que están tan generalizados en las aplicações que las netops pueden escribir los comandos necesarios mientras duermen. Las únicas desviaciones son las variables específicas de la aplicación, como puertos, direcciones IP y rutas. Éstos son los cambios que les gustan a las juntas de revisión, porque no tienen que pensar en ellos. "Ah, vas a añadir una regla de firewall para esa aplicación. Aprobado".

Al igual que la atención que se requiere de los netops para ejecutarlos, su aprobación requiere muy poca consideración porque se ha hecho cientos de veces, el proceso es siempre el mismo y todos saben lo que está pasando. Son consistentes, predecibles y repetibles.

Aprobado.

Se trata de procesos internos de TI mercantilizados que están listos para la automatización y la orquestación . Estos son los mejores lugares para comenzar si está buscando ganancias rápidas para demostrar el valor comercial de invertir en esfuerzos de automatización. Construya una interfaz sobre ese proceso mercantilizado e incorpórela al proceso (integración) en lugar de los métodos manuales que se utilizan hoy en día. Listo. Ha reducido los costos de ejecutar ese proceso y, como beneficio adicional, será más rápido porque no tendrá que esperar hasta la próxima reunión de la junta de control de cambios (de hecho, es posible que pueda saltearla, lo que en sí mismo es un beneficio).

Sí, requiere tiempo y probablemente dinero (y tal vez inversión en herramientas y capacitación), pero los costos a corto plazo darán sus frutos en el largo plazo. La automatización de procesos que consumen mucho tiempo y que se han convertido en productos básicos libera a ingenieros y arquitectos para trabajar en otros proyectos. Proyectos que probablemente no sean aprobados automáticamente por la junta de control de cambios.

SaaS gana cuando analiza un negocio, entiende un proceso común y ofrece una forma más fácil y rápida de navegarlo. Eso era cierto en 2006 y sigue siendo cierto hoy. Lo mismo ocurre con los esfuerzos de automatización de la infraestructura. Encuentre los procesos comunes y proporcione una forma más fácil y rápida de navegar por ellos, ya sea para el “usuario final” u otros ingenieros.