De las soluciones a las pilas: La era de la asamblea
Esta componentización de TI es como la componentización de las aplicações que se encarga de proteger y entregar. Se estima que entre el 80 y el 90% de las aplicações modernas están compuestas por componentes de terceros, la mayoría de los cuales son de código abierto. Los beneficios de hacerlo incluyen velocidad, capacidad de respuesta al cambio (agilidad) y una reducción en el costo de creación del software. Después de todo, si alguien más ya escribió el código de una rueda, ¿por qué reinventarla?
No existen estimaciones sobre cuán componentizada puede ser la TI hoy, pero la respuesta a cuán componentizada será en el futuro es clara: Muy.
Ya no construimos nuestros propios sistemas de vigilancia. Adoptamos uno, como Prometeo. No desarrollamos nuestros propios motores de búsqueda; nos integramos con Elastic Search o Lucerne. No tenemos que diseñar y desarrollar controladores de formación e infraestructura; tenemos Helm y Terraform. Ya no nos preguntan sobre la integración con los sistemas; nos preguntan sobre nuestro apoyo a los ecosistemas.
Construimos sistemas a partir de una pila de software en lugar de desarrollar cada componente nosotros mismos.
El efecto dominó de la componentización
Este pensamiento a nivel de sistema está omnipresente en el desarrollo y está empezando a tener un profundo impacto en la forma en que se desarrolla todo el software (comercial y personalizado). También está teniendo un impacto significativo en la forma en que diseñamos la red.
Hace unos años observé que los microservicios estaban desintegrando la red . Esto sigue siendo una ruptura en progreso, por razones que están estrechamente vinculadas a la mentalidad de DevOps. Es decir, es más probable que DevOps piense en términos de sistemas componentizados, particularmente cuando está influenciado por la nube. A medida que DevOps continúa invadiendo el territorio de las operaciones y NetOps tradicionales, trae consigo su forma de pensar. Esto significa pilas en lugar de soluciones.
Esta perspectiva conduce naturalmente a la adopción de servicios de aplicação individuales que se adapten mejor al modo de operación y pensamiento en el que DevOps opera hoy. Los servicios de aplicação centrados en funciones y de propósito único se utilizan para componer una ruta de datos en lugar de construir una.
Eso significa que el equilibrio de carga es equilibrio de carga. El control de entrada es el control de entrada. Y una puerta de enlace API es una puerta de enlace API. Con una variedad de servicios de aplicação , los artesanos operativos componen (ensamblan) una ruta de datos que se extiende desde el código (la aplicación) hasta el cliente.
Podemos ver esto en las extraordinarias tasas de adopción de servicios específicos como API Gateway, control de ingreso y defensa contra bots que vimos en el informe Estado de los servicios de aplicação de este año.
Este cambio no ha pasado desapercibido. Así como la transformación digital continúa obligando a las empresas a redefinirse y descomponerse en servicios representados por API y aplicações (capacidades digitales), cambia drásticamente la forma en que diseñamos, desarrollamos y entregamos servicios de aplicação .
Subiendo la pila
El enrutamiento basado en IP siempre ha sido la forma en que se diseñan las rutas de datos. Enruta este tráfico aquí, y este tipo de tráfico allá, y si hay algo en la carga útil que coincide con X, entonces enruta el tráfico hacia allá. Es muy específico de la red y, por lo tanto, acopla estrechamente la ruta de datos a la red en la que está implementado.
Esto hace que sea difícil replicarlo en otros entornos, como una nube pública. Si bien es posible reutilizar las políticas, no podrá aprovechar la configuración que vincula la ruta de datos a la red.
Tanto los contenedores como la nube básicamente obligan a las rutas de datos a ascender en la pila y a ensamblarse en la capa de aplicação desde los servicios de aplicação . Esto es mucho más portable entre entornos porque estás operando con metadatos como nombres de host o etiquetas que no están vinculados a la red.
En última instancia, eso significa que debemos dejar de lado las configuraciones y adoptar políticas que puedan ensamblar rutas de datos sin estar limitadas a direcciones IP y entornos.
No hay duda de que estamos pasando de soluciones a pilas, de procesos manuales a pipelines. A medida que ampliamos nuestras capacidades digitales en los negocios y las operaciones, la necesidad de composición y control sobre la ruta de datos seguirá ascendiendo en la pila y dependerá cada vez más de los servicios de aplicaciones que la dirigen.