Cuando nos dimos cuenta de que sería aburrido celebrar la próxima reunión, decidimos convertirlo en algo más lleno de acción. A saber, en un duelo, en un
duelo entre dos enfoques de integración, ESB y Distribuido, cuyo honor fue defendido por expertos de peso pesado. En esta publicación, le diremos cómo fue la batalla y descubriremos al ganador.
Algunas palabras sobre el formato
Alexander Trekhlebov , nuestro arquitecto corporativo, habló por el autobús centralizado. Para la descentralización: Andrey Trushkin, jefe del centro de innovación y tecnologías prometedoras de Promsvyazbank. Se turnaron para dar informes sobre sus tecnologías y respondieron varias preguntas, provocativas y no muy. Así fue como fue.
¿Por qué es genial ESB?
Para empezar, debe ponerlo en conocimiento y decir cómo comenzó todo. Probablemente muchos recuerden que en la primera etapa todo sucedió sin ninguna integración, cuando cada sistema se comunicaba y realizaba sus pruebas de integración con cualquier otro sistema.
En consecuencia, si una persona renuncia o le sucede algo más, entonces nadie sabe cómo funcionaría todo esto. Cada computadora interactuó con algún servidor. ¿Qué protocolo, qué tipo de interacción? Solo la persona que trabajaba en el sistema sabía todo esto.
Luego vino el bus de integración. Parecía no solo así, sino porque los principales protocolos y métodos de interacción se recopilaron en él y era posible no obligar al sistema a describir cosas específicas. Podía comunicarse con ellos usando sus algoritmos internos.
Además, resultó que la mayoría de las veces se comunican con el autobús a través de colas o mediante REST.
Con el tiempo, sin embargo, la necesidad de un autobús y REST en muchos casos desapareció. Pero parecía un retroceso, las preguntas importantes volvieron a surgir:
- Cómo orquestar si no hay neumáticos. ¿Dónde va a pasar esto?
- ¿Qué hacer con los formatos de datos y protocolos?
Además, el rendimiento en un sistema centralizado es mucho mejor que en Distribuido. Puede contar con la velocidad, el volumen y la disponibilidad. Todo esto porque es un sistema que un equipo en particular está atendiendo.
¿Cuán vulnerable es este sistema? ¿Qué sucede si una computadora es pirateada?Siempre hay redundancia y centralización. En caso de que uno esté fuera de servicio, el sistema funcionará.
¿Quién es responsable del neumático? ¿Su equipo o desarrolladores de terceros?En el equipo interno, brindamos servicios operativos, brindamos confiabilidad y monitoreo. Si algo no funciona, sabemos dónde buscar. Hay una pregunta: "¿Es posible confiar en los proveedores en tales casos y en equipos de terceros?" Se necesita un buen monitoreo aquí. Porque la calidad, en cualquier caso, es responsabilidad del equipo interno.
A medida que crece el autobús, los servicios no se conectan. ¿Cambian los servicios con lanzamientos o qué? ¿Qué hacer con Agile?Aquí llegamos a la pregunta fundamental.
La integración no es una aplicación. Solía ser parte, pero ahora no lo es. El desarrollo de integración no es desarrollo de aplicaciones. Es el desarrollo de interacciones de integración o el desarrollo dentro del marco de un proyecto separado, pero no específicamente de una aplicación.
Sus inquietudes ágiles son comprensibles. Este modelo se usa cuando hacemos un sistema separado que está conectado al bus en algún lado del lado. Cuando trabajaba en otro banco, existía ese sistema: un mes de pruebas, un mes de desarrollo. Como resultado, todas las interacciones de integración se implementan rápidamente en el bus. Incluso más rápido de lo que los analistas los describen, porque los sistemas de desarrollo son bastante sofisticados y simples. Y ágil se utiliza en el desarrollo del sistema final.
¿Cuánto tiempo busca el equipo el servicio que necesita y dónde lo busca?Todos tienen el sueño de que haya un mapa mundial en el que todas las principales áreas de negocios se encuentren dispersas por los continentes. E incluso se implementa parcialmente. El analista va allí y comienza a deambular intensamente por los continentes, después de un tiempo encuentra la interacción que se necesita. Además, si todo encaja perfectamente, simplemente lo usa. Si no, describe en TK qué adiciones necesita. Sería genial tener esa opción, pero hasta ahora los sistemas menos convenientes que requieren mucho más tiempo y esfuerzo para trabajar con ellos son relevantes.
¿O tal vez Service Mesh es más genial?
Para empezar, mucho ha cambiado realmente en 3-4 años. ¿Pero qué pasó exactamente? Ha sucedido la misma banalidad que todos los hablantes repiten regularmente, y por la cual tampoco podemos pasar: el mundo está cambiando.
Los requisitos para la velocidad de cambio se están volviendo enormes. Al mismo tiempo, los requisitos de fiabilidad, los requisitos de seguridad no desaparecen en ningún lado y los requisitos de carga solo aumentan. Como podemos ver, todos están tratando de capturar participación de mercado, lo que inevitablemente conduce a un aumento de la carga sobre los sistemas corporativos y, en consecuencia, sobre la integración.
De hecho, el ESB en un momento muy bueno ayudó como plantilla para la implementación técnica en términos de descentralización de aplicaciones, la asignación de lógica entre diferentes aplicaciones, un dispositivo unificado para integrar aplicaciones entre sí. Digamos condicionalmente unificado.
Ahora imaginemos que no hay 20 sistemas en la empresa; después de todo, busca pasar a la arquitectura que se llama la palabra de moda "microservicios". ¿Y qué es un microservicio? Hay muchas definiciones, una de ellas es utilizada periódicamente por Martin Fowler: es un servicio que un desarrollador medio puede desarrollar en un sprint. Imagine cuántos servicios de este tipo habrá en una gran empresa. Por ejemplo, Netflix estima el número de sus microservicios en 800-900. En principio, en una empresa que busca construir un ecosistema externo asociado, estos servicios pueden superar los mil. Pero cada uno de estos servicios a largo plazo soporta una carga tremenda y debe desarrollarse independientemente.
¿Qué hay del autobús? Si el autobús sigue siendo este complejo común entre ellos, resulta que se convierte en un cuello de botella y retrasa el desarrollo de los servicios. No solo porque está esperando estos servicios, sino porque se está desarrollando como un equipo separado, por personas que poseen estas mismas tecnologías y habilidades.
Y ahora imaginemos: varias docenas de equipos de productos están desarrollando y trabajando con nosotros. Y cada uno de ellos vio varios servicios. Y el autobús es conducido por dos equipos. Naturalmente, estos equipos con un alto grado de probabilidad no podrán desarrollar esta integración con el nivel necesario de velocidad y calidad.
Surge la pregunta: "¿Cómo podemos garantizar la misma velocidad rápida sin perder accesibilidad, seguridad, etc.?" La respuesta es muy simple: "Deje que estos servicios interactúen directamente, sin un intermediario explícito".
Luego se plantea la siguiente pregunta importante: "¿Cómo se aprenden los servicios unos de otros?" Y aquí la respuesta también es muy simple: puede crear un sistema con el cual los servicios mismos informarían sobre sí mismos. Es decir, en el momento en que se desarrolla el servicio, publicará de forma independiente información sobre sí mismo en un determinado registro. Y en base a esta información, todos los servicios podrán comenzar a interactuar con él.
Por lo tanto, se formó el concepto de una "cuadrícula" de servicios, como se llamaba originalmente,
"malla de servicios" . Como una especie de nivel intermedio de integración entre servicios, que proporciona dicha integración, como si fuera una solución en la nube.
Las grandes empresas ahora están tratando de resolver los problemas de velocidad de desarrollo en paralelo, para encontrar una cierta solución general, distribuida y a menudo integrada. En este caso, cada servicio utiliza un conjunto particular de bibliotecas preparadas para publicar automáticamente información en un registro durante la implementación.
A menudo surge la pregunta: "¿Pero qué hacer con el modelo de datos canónicos, cuya fuente, por regla general, era el ESB, en el que se invirtió tanto dinero y esfuerzo para implementarlo y mantenerlo?" Después de todo, ella era una modelo estándar. Aquí hay una contrapregunta: “¿Y qué ventajas nos trajo? ¿Y no fue el punto que retrasó nuestro desarrollo? " De hecho, al desarrollar servicios, el modelo se expande más y más. Siempre habrá desafíos más nuevos.
Para decirlo sin rodeos, el
costo de agregar nuevos dispositivos, organizar la interacción, etc., por regla general, es significativamente menor que el costo de mantener actualizado el modelo de datos ESB canónico .
Además, la integración descentralizada garantiza en gran medida la misma alta disponibilidad. Cada uno de los microservicios es independiente, incluso de otros microservicios, pero depende de manera crítica de la carga externa que se le aplica. Implementado en paralelo con la integración también se puede implementar tecnológicamente de forma independiente.
A veces, el uso de un ESB bastante pesado en condiciones modernas no tiene sentido, o incluso viceversa, reduce la calidad de la solución. La aplicación de tecnologías sin servidor, la infraestructura misma que no se adapta a las necesidades efímeras de las soluciones que se crean, ya está al borde, pero ya se entrega en la forma correcta para un servicio específico. Ahora parece algo muy distante, pero el mundo está cambiando, como ya se ha dicho, bastante rápido.
Muchos proveedores de software van por este camino en términos de sus soluciones de integración. Ya existen marcos que esencialmente implementan el concepto de malla de servicio (el mismo Linkerd o Istio). Ya está sucediendo lo mismo como parte del alojamiento de una gran cantidad de servidores proxy de red y servicios de integración de malla de servicios. Mucho en común con la malla de servicios y los sistemas de orquestación de contenedores como Kubernetes.
¿Es posible construir distribuido basado en ESB? Es decir, ¿es posible hacer otro a partir de un sistema? Y si es así, ¿cuál es el punto de estas disputas?Aquí me vienen a la mente Hegel y su "negación de la negación". Cuando una idea se repite en un nivel histórico más alto. Venir de uno a otro, en mi opinión, es posible. Otra pregunta es cómo haremos esto. De hecho, en esencia, el concepto mismo de microservicios y su implementación es en muchos aspectos similar al concepto de integración que originalmente era: la interacción de microservicios entre ellos, cada uno con cada uno.
¿Es posible llegar a la integración de acuerdo con los principios de la red, si pasamos del ESB? En realidad, Red Hat, ahora IBM, ya sigue el mismo principio. Basta con ver su comprensión del concepto de la pila de integración y la integración flexible (Integración ágil). Ofrecen una gran cantidad de proxies de integración que no están sobrecargados de lógica. Lo más importante es la transparencia y el conocimiento de los servicios que requieren todos los nuevos participantes en la interacción.
¿Entiende su banco que el ESB ha sobrevivido si continúa invirtiendo presupuestos significativos en él?Francamente, los problemas presupuestarios son un secreto comercial. En cuanto a los enfoques utilizados, en este momento estamos desarrollando un paralelo de dos enfoques. En Promsvyazbank realmente hay muchos sistemas vinculados al autobús. Todavía están integrados a través del autobús. Pero, por nuestra parte, entendemos que ESB es un enfoque poco prometedor y es más eficiente invertir en integraciones distribuidas sin usar un bus. Esta es nuestra prioridad estratégica ahora.
¿Dónde está el lugar para el monitoreo de negocios en un sistema distribuido?En la integración descentralizada, la presencia de una gran cantidad de servicios no excluye la presencia de monitoreo comercial. Todo esto puede establecerse a nivel de los respectivos marcos. En consecuencia, este monitoreo puede fusionar información en un determinado almacenamiento responsable de los datos. Estos datos se analizan allí y se prepara un informe resumido.
¿Cómo ve el plan para la transición a la integración descentralizada?La transición a la integración descentralizada tiene sentido a considerar en el contexto de la transición a nuevos principios arquitectónicos. Esta es una transición compleja que no puede suceder de inmediato. Sí, puede intentar mantenerlo en el formato de "big bang", pero esta opción de escenario conlleva serios riesgos. Más lógica es la opción de crear un nuevo circuito en paralelo con el existente y, a medida que se crea (en modo iterativo), introducir nuevos productos en él. A medida que se desarrolla el nuevo contorno arquitectónico, los productos del panorama actual de TI que han resistido la prueba del tiempo pueden transferirse allí. Tal camino es bastante largo, se estima hasta 4-5 años, pero debido a la iteración, es posible obtener resultados en el modo de operación industrial en secuencia.
Quien ganó
Después de tres rondas interactivas con presentaciones, preguntas y respuestas, la audiencia se escondió anticipando el anuncio del resultado final. Probablemente te des cuenta de que el ganador de la Batalla de PSB fue Andrey Trushkin y el sistema distribuido.
En conclusión, ofrecemos un video que ayudará a sentir la atmósfera de nuestra batalla: