A veces, la estandarización se percibe como un ataque a la innovación. Verse obligado a renunciar a un amplio abanico de lenguajes y adoptar un repertorio más limitado resulta, sin duda, asfixiante. Esto puede deberse a que la estandarización suele asociarse con normas de cumplimiento regulatorio que tienen nombres de carácter oficial, como ISO 8076.905E, y que conllevan listas de comprobación, auditores y comités de supervisión.
La realidad es que existen muy pocos estándares —de hecho, no se me ocurre ninguno— que rijan la elección de lenguajes, protocolos y marcos de trabajo por parte de las organizaciones empresariales. Lo que impulsa la estandarización en la empresa son consideraciones más prácticas, como la disponibilidad de profesionales cualificados, la sostenibilidad y el coste total de propiedad a lo largo de la vida útil —a menudo considerable— del software y los sistemas.
Los estudios han demostrado que la vida útil media del software durante los últimos veinte años se sitúa entre 6 y 8 años. Curiosamente, la longevidad tiende a aumentar en los programas de mayor tamaño, medido en líneas de código (LOC). Los sistemas y el software con más de un millón de LOC parecen tener una vida útil superior a una década, de entre 12 y 14 años. Aunque pueda parecerte irrelevante, es importante comprender que, al fin y al cabo, los sistemas de automatización de redes son software y sistemas. Necesitan los mismos cuidados, recursos y mantenimiento que el software creado por tu organización de desarrollo. Si vas a tratar tu canalización de producción como código, debes aceptar que un porcentaje significativo de esa canalización automatizada va a ser código.
Por tanto, a lo largo de la vida útil de ese software o sistema, es prácticamente seguro que varios equipos de operadores y desarrolladores se encargarán de actualizarlo, mantenerlo y operarlo, así como de implementar cambios en él.
Y esto es precisamente lo que constituye el núcleo del impulso hacia la estandarización, especialmente para los equipos de NetOps, que se adentran en el desarrollo y mantenimiento de sistemas destinados a automatizar y orquestar el despliegue y el funcionamiento de la infraestructura de servicios de red y aplicaciones.
Los silos son para las granjas
Si usted (o su equipo) elige Python mientras otro equipo elige PowerShell, estará creando en la práctica un silo operativo que impide compartir conocimientos. Dado que el principal reto al que se enfrentaban los equipos de operaciones de red, según el informe Estado de la automatización de redes 2018, era la falta de conocimientos (señalada por el 49 %), no parece sensato añadir más obstáculos introduciendo varios lenguajes o conjuntos de herramientas. Tampoco es buena idea elegir lenguajes y conjuntos de herramientas para los que no haya profesionales cualificados en la zona. Si otras organizaciones y universidades cercanas enseñan Python y usted opta por PowerShell, le resultará difícil encontrar personas con los conocimientos necesarios para trabajar en ese sistema.
Es poco habitual que una organización se estandarice en un único lenguaje, pero sí suele limitarse a unos pocos. NetOps debería guiarse por los estándares de desarrollo y DevOps, ya que esto ampliará aún más la reserva de talento disponible.
El tiempo de obtención de valor es valioso
Muchas organizaciones de NetOps ya se encuentran en desventaja a la hora de satisfacer las exigencias de DevOps y del negocio para lograr una entrega continua. La desafortunada realidad de NetOps y la automatización de redes es que se trata de un ecosistema heterogéneo con muy pocas integraciones listas para usar. En la encuesta sobre el estado de la automatización de redes, descubrimos que esta «falta de integración» era el segundo obstáculo para la automatización más citado, señalado por el 47 % de los profesionales de NetOps.
La estandarización de los conjuntos de herramientas y, cuando sea posible, de la infraestructura (como los servicios de aplicaciones) permite reducir la carga que supone la integración en toda la organización. Lo que desarrolla un equipo puede ser aprovechado por otros para acortar el tiempo de obtención de valor de otros proyectos de automatización. La reutilización es un factor importante para mejorar este plazo. Esto se refleja en la preferencia de los desarrolladores por el código abierto y en el hecho de que, actualmente, entre el 80 % y el 90 % de las aplicaciones están compuestas por componentes de terceros o de código abierto. Esto acelera el desarrollo y reduce el tiempo de obtención de valor. El mismo principio puede aplicarse a la automatización de redes aprovechando las integraciones existentes.
Establezca una cultura de intercambio y reutilización entre los distintos ámbitos operativos para aprovechar las ventajas de la estandarización.
Impulsar la innovación
En lugar de obstaculizar la innovación, como algunos creen en un principio, la estandarización puede actuar como catalizador de esta. Al estandarizar y compartir software y sistemas entre distintos ámbitos operativos, se dispone de un conjunto más amplio y sólido de conocimientos y experiencias capaz de colaborar en nuevos requisitos y sistemas. De este modo, se crea una reserva de talento dentro de la organización que puede contribuir con aportaciones e ideas, así como implementar nuevas características y funcionalidades, sin tener que pasar por un proceso de incorporación que, en ocasiones, puede ser largo.
La estandarización también agiliza la implementación gracias a la familiaridad. Cuanto más se trabaja con el mismo lenguaje, las mismas bibliotecas y los mismos conjuntos de herramientas, mayor es la competencia adquirida. Esto se traduce en una mayor productividad, lo que permite dedicar menos tiempo a reinventar la rueda y más a pensar en cómo diferenciarse y aportar valor mediante nuevas funcionalidades.
La estandarización es una oportunidad
Al principio, la estandarización puede resultar restrictiva, sobre todo si el lenguaje o el conjunto de herramientas que prefieres deja de utilizarse en el equipo. Sin embargo, adoptar la estandarización como una oportunidad para crear una base sólida para los sistemas y el software de automatización beneficia a la empresa y brinda a NetOps nuevas oportunidades para aportar valor en toda la cadena de herramientas de despliegue continuo.
Pero no estandarice por el mero hecho de estandarizar. Tenga en cuenta las competencias existentes y la disponibilidad de talento en su zona. Consulte a universidades y otras empresas para conocer la situación actual de las competencias y el talento en materia de automatización y operaciones, y asegurarse de que su organización no sea la única que adopte un determinado lenguaje o conjunto de herramientas.
Para obtener los mejores resultados a largo plazo, no trate la estandarización como la seguridad, dejándola para después de haber completado una implementación. Adopte la estandarización desde el principio en sus iniciativas de automatización para evitar una deuda operativa y arquitectónica que suponga una carga y dificulte la estandarización más adelante.
En lo que respecta a la estandarización —al igual que a la seguridad—, cuanto antes, mejor.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.