El 25 de abril, en Mail.ru Group celebramos una conferencia sobre las nubes y sus alrededores: . Algunos aspectos destacados:
- El principal — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center y Yandex.Cloud hablaron sobre las particularidades de nuestro mercado de la nube y sus servicios;
- Los colegas de Bitrix24 contaron cómo ;
- Leroy Merlin, Otkritie, Burger King y Schneider Electric aportaron interesantes — qué tareas asigna su negocio a TI y qué tecnologías, incluidas las de nube, consideran más prometedoras.
Puedes ver todos los vídeos de la conferencia mailto:CLOUD , y aquí puedes leer cómo fue la discusión sobre microservicios. Alexander Deulin, director del centro de investigación y desarrollo de sistemas empresariales MegaFon, y Sergey Sergeev, director de tecnología de la información del grupo M.Video-Eldorado, compartieron sus casos exitosos de eliminación de monolitos. También discutimos temas relacionados con la estrategia de TI, los procesos e incluso los recursos humanos.
Panelistas
- Sergey Sergeev, CIO del grupo "M.Video-Eldorado";
- Alejandro Deulin, jefe del centro de investigación y desarrollo de sistemas empresariales megáfono;
- Moderador— Dmitri Lazarenko, Responsable de la dirección PaaS Soluciones en la nube Mail.ru.
Después del discurso de Alexander Deulin. A él se unen para la discusión Sergey Sergeev de M.Video-Eldorado y el moderador de la discusión Dmitry Lazarenko, Mail.ru Cloud Solutions.
A continuación hemos preparado una transcripción del debate para usted, pero también puede ver el vídeo:
La transición a los microservicios es una respuesta a las necesidades del mercado
Dmitry:
¿Ha tenido alguna experiencia exitosa al migrar a microservicios? Y en general: ¿dónde ve el mayor beneficio empresarial al utilizar microservicios o pasar de monolitos a microservicios?
Sergey:
Ya hemos avanzado un poco en la transición a los microservicios y hemos estado utilizando este enfoque durante más de tres años. La primera necesidad que justificó la necesidad de microservicios fue la integración interminable de varios productos front-end con el back office. Y cada vez nos vimos obligados a realizar una integración y un desarrollo adicionales, implementando nuestras propias reglas para el funcionamiento de tal o cual servicio.
En algún momento, nos dimos cuenta de que necesitábamos acelerar el funcionamiento de nuestros sistemas y la producción de funcionalidades. En ese momento ya existían en el mercado conceptos como microservicios y un enfoque de microservicio, y decidimos probarlo. Esto comenzó en 2016. Luego se colocó la plataforma y un equipo independiente implementó los primeros 10 servicios.
Uno de los primeros servicios, el más cargado, fue el servicio de cálculo de precios. Cada vez que ingresa a cualquier canal, al grupo de empresas M.Video-Eldorado, ya sea un sitio web o una tienda minorista, selecciona un producto allí, mira el precio en el sitio web o en la “Cesta”, el costo se calcula automáticamente. calculado por un servicio. ¿Por qué es necesario? Antes de esto, cada sistema tenía sus propios principios para trabajar con promociones, con descuentos, etc. Nuestro back office maneja los precios; la funcionalidad de descuento se implementa en otro sistema. Esto debía centralizarse y crearse un servicio único y separable en forma de proceso de negocio que nos permitiera implementarlo. Así es como empezamos.
El valor de los primeros resultados fue muy grande. En primer lugar, pudimos crear entidades separables que nos permiten trabajar de forma separada y agregada. En segundo lugar, hemos reducido el coste de propiedad en términos de integración con más sistemas.
En los últimos tres años, hemos agregado tres sistemas de primera línea. Era difícil mantenerlos con la misma cantidad de recursos que la empresa podía permitirse. Por tanto, surgió la tarea de buscar nuevas salidas, respondiendo al mercado en términos de rapidez, en términos de costos internos y eficiencia.
Cómo medir el éxito de la migración a microservicios
Dmitry:
¿Cómo se determina el éxito de la migración a microservicios? ¿Cuál fue el “antes” en cada empresa? ¿Qué métrica utilizó para determinar el éxito de la transición y quién realmente la determinó?
Sergey:
En primer lugar, nació dentro de TI como un facilitador: “desbloquear” nuevas capacidades. Teníamos la necesidad de hacer todo más rápido por relativamente el mismo dinero, respondiendo a los desafíos del mercado. Ahora el éxito se expresa en la cantidad de servicios reutilizados por diferentes sistemas, unificación de procesos entre ellos. Ahora lo es, pero en ese momento era una oportunidad para crear una plataforma y confirmar la hipótesis de que podemos hacer esto, dará un efecto y calculará el caso de negocio.
Alexander:
El éxito es más bien un sentimiento interno. Las empresas siempre quieren más y la profundidad de nuestro trabajo pendiente es prueba de éxito. A mí me parece que sí.
Sergey:
Sí estoy de acuerdo. En tres años ya contamos con más de doscientos servicios y cartera. La necesidad de recursos dentro del equipo no hace más que crecer: un 30% anual. Esto sucede porque la gente sintió: es más rápido, es diferente, hay diferentes tecnologías, todo esto se está desarrollando.
Los microservicios llegarán, pero el núcleo permanecerá
Dmitry:
Es como un proceso interminable en el que se invierte en desarrollo. ¿La transición a los microservicios para empresas ya ha terminado o no?
Sergey:
Es muy fácil de responder. ¿Qué opinas: reemplazar teléfonos es un proceso interminable? Nosotros mismos compramos teléfonos todos los años. Y aquí está: mientras exista necesidad de velocidad, de adaptación al mercado, serán necesarios algunos cambios. Esto no significa que abandonemos las cosas estándar.
Pero no podemos cubrir y rehacer todo a la vez. Contamos con servicios de integración estándar heredados que existían antes: autobuses empresariales, etc. Pero hay un retraso y también una necesidad. El número de aplicaciones móviles y su funcionalidad está creciendo. Al mismo tiempo, nadie dice que te darán un 30% más de dinero. Es decir, siempre hay necesidades por un lado y búsqueda de eficiencia por el otro.
Dmitry:
La vida está en buena forma. (Risas)
Alexander:
En general, sí. No tenemos enfoques revolucionarios para eliminar la parte central del paisaje. Se está realizando un trabajo sistemático para descomponer los sistemas de modo que sean más coherentes con la arquitectura de microservicios y reducir la influencia de los sistemas entre sí.
Pero planeamos mantener la parte central, ya que en el panorama de operadores siempre habrá algunas plataformas que compremos. Una vez más, necesitamos un equilibrio saludable: no debemos apresurarnos a eliminar el núcleo. Colocamos los sistemas uno al lado del otro y ahora resulta que ya estamos encima de muchas partes centrales. Además, desarrollando la funcionalidad, creamos las representaciones necesarias para todos los canales que trabajan con nuestros servicios de comunicación.
Cómo vender microservicios a empresas
Dmitry:
También me interesa, para aquellos que no han hecho el cambio, pero están planeando hacerlo: ¿qué tan fácil fue vender esta idea a las empresas? ¿Fue una aventura, un proyecto de inversión? ¿O fue una estrategia consciente: ahora vamos a los microservicios y ya está, nada nos detendrá? que te parecio?
Sergey:
No vendíamos un enfoque, sino un beneficio empresarial. Había un problema en el negocio y tratamos de solucionarlo. En ese momento, se expresó en el hecho de que diferentes canales utilizaban diferentes principios para calcular los precios: por separado para promociones, promociones, etc. Era difícil de mantener, se producían errores y escuchábamos las quejas de los clientes. Es decir, estábamos vendiendo una solución a un problema, pero venimos con el hecho de que necesitábamos dinero para crear una plataforma. Y mostraron un caso de negocio usando el ejemplo de la primera etapa de inversión: cómo continuaremos recuperándola y qué nos permitirá hacer esto.
Dmitry:
¿Registraste de alguna manera el tiempo de la primera etapa?
Sergey:
Si seguro. Dedicamos 6 meses para crear el núcleo como plataforma y probar el piloto. Durante este tiempo, intentamos crear una plataforma sobre la que patinar el piloto. Entonces se confirmó la hipótesis y, como funciona, significa que podemos continuar. Comenzaron a replicar y fortalecer el equipo: lo trasladaron a una división separada que hace precisamente eso.
Luego viene el trabajo sistemático basado en las necesidades del negocio, las oportunidades, la disponibilidad de recursos y todo lo que se está trabajando actualmente.
Dmitry:
DE ACUERDO. Alejandro, ¿qué dices?
Alexander:
Nuestros microservicios nacieron de la "espuma del mar", gracias al ahorro de recursos, a algunos sobrantes en forma de capacidad del servidor y a la redistribución de fuerzas dentro del equipo. Inicialmente, no vendimos este proyecto a empresas. Este fue un proyecto en el que investigamos y desarrollamos en consecuencia. Comenzamos a principios de 2018 y simplemente desarrollamos esta dirección con entusiasmo. Las ventas acaban de comenzar y estamos en el proceso.
Dmitry:
¿Sucede que una empresa le permite hacer cosas como Google, un día libre a la semana? ¿Tienes esa dirección?
Alexander:
Al mismo tiempo que investigamos, también nos ocupamos de problemas comerciales, por lo que todos nuestros microservicios son soluciones a problemas comerciales. Solo al principio creamos microservicios que cubrían una pequeña parte de la base de suscriptores y ahora estamos presentes en casi todos los productos estrella.
Y el impacto material ya es claro: ya se nos puede contar, se puede estimar la velocidad de los lanzamientos de productos y la pérdida de ingresos si hubiéramos seguido el camino anterior. Esto es sobre lo que estamos construyendo el caso.
Microservicios: ¿exageración o necesidad?
Dmitry:
Los números son números. Y los ingresos o el dinero ahorrado son muy importantes. ¿Y si miras al otro lado? ¿Parece que los microservicios son una tendencia, un hype y muchas empresas están abusando de ello? ¿Con qué claridad diferencia entre lo que hace y lo que no traduce a microservicios? Si es un legado ahora, ¿seguirá teniendo un legado dentro de 5 años? ¿Cuál será la edad de los sistemas de información que funcionan en M.Video-Eldorado y MegaFon dentro de 5 años? ¿Habrá sistemas de información de diez, quince años o será una nueva generación? Como ves esto?
Sergey:
Me parece que es difícil pensar muy lejos. Si miramos atrás, ¿quién imaginaba que el mercado tecnológico se desarrollaría de esta manera, incluyendo el aprendizaje automático y la identificación facial del usuario? Pero si nos fijamos en los próximos años, me parece que los sistemas centrales, los sistemas empresariales de clase ERP en las empresas, han estado funcionando durante bastante tiempo.
Nuestras empresas tienen en conjunto 25 años y el ERP clásico está muy arraigado en el panorama de los sistemas. Está claro que estamos sacando algunas piezas de allí e intentando agregarlas en microservicios, pero el núcleo permanecerá. Ahora me resulta difícil imaginar que reemplazaremos todos los sistemas centrales allí y pasaremos rápidamente al otro lado positivo de los nuevos sistemas.
Soy partidario de que todo lo que está más cerca del cliente y consumidor es donde está el mayor beneficio y valor empresarial, donde está la adaptabilidad y el enfoque en la velocidad, en el cambio, en el “probar, cancelar, reutilizar, hacer algo diferente”. necesario “—ahí es donde el panorama cambiará. Y los productos en caja no encajan muy bien allí. Al menos no lo vemos. Allí se necesitan las soluciones más sencillas y sencillas.
Vemos este desarrollo:
- sistemas de información básicos (principalmente back office);
- las capas intermedias en forma de microservicios conectan el núcleo, agregan, crean un caché, etc.
- los sistemas de primera línea están dirigidos al consumidor;
- una capa de integración que generalmente está integrada en los mercados, otros sistemas y ecosistemas. Esta capa es lo más ligera posible, simple y contiene un mínimo de lógica empresarial.
Pero al mismo tiempo soy partidario de seguir utilizando los viejos principios si se utilizan adecuadamente.
Digamos que tiene un sistema empresarial clásico. Está ubicado en el paisaje de un proveedor y consta de dos módulos que funcionan entre sí. También hay una interfaz de integración estándar. ¿Por qué rehacerlo y traer un microservicio allí?
Pero cuando hay 5 módulos en el back office, a partir de los cuales se recopila información en un proceso de negocio, que luego es utilizado por 8 a 10 sistemas de primera línea, el beneficio se nota de inmediato. Se toma de cinco sistemas administrativos y se crea un servicio, aislado, que se centra en el proceso de negocio. Haga que el servicio sea tecnológicamente avanzado, para que almacene información en caché y sea tolerante a fallas, y también funcione con documentos o entidades comerciales. Y lo integra según un principio único con todos los productos de primera línea. Cancelaron el producto de primera línea, simplemente desactivaron la integración. Mañana necesitarás escribir una aplicación móvil o crear un pequeño sitio web y poner en funcionamiento solo una parte; todo es simple: lo ensamblaste como un constructor. Veo más desarrollo en esta dirección, al menos en nuestro país.
Alexander:
Sergey describió completamente nuestro enfoque, gracias. Solo diré dónde definitivamente no iremos: a la parte central, al tema de la facturación en línea. Es decir, la calificación y el cobro seguirán siendo, de hecho, una "gran" trilladora que amortizará el dinero de forma fiable. Y este sistema seguirá estando certificado por nuestras autoridades reguladoras. Todo lo demás que mira hacia los clientes, por supuesto, son microservicios.
Dmitry:
Aquí la certificación es una historia. Probablemente más apoyo. Si gastas poco en soporte o el sistema no requiere soporte y modificación, es mejor no tocarlo. Un compromiso razonable.
Cómo desarrollar microservicios confiables
Dmitry:
Bien. Pero todavía estoy interesado. Ahora estás contando una historia de éxito: todo estuvo bien, cambiamos a microservicios, defendimos la idea ante el negocio y todo salió bien. Pero he oído otras historias.
Hace un par de años, una empresa suiza que había invertido dos años en el desarrollo de una nueva plataforma de microservicios para bancos finalmente cerró el proyecto. Completamente colapsado. Se gastaron muchos millones de francos suizos y al final el equipo se dispersó y no funcionó.
¿Has tenido historias similares? ¿Hubo o hay dificultades? Por ejemplo, mantener microservicios y monitorear también es un dolor de cabeza en las actividades operativas de la empresa. Después de todo, la cantidad de componentes aumenta decenas de veces. ¿Cómo lo ve? ¿Ha habido aquí ejemplos de inversiones fallidas? ¿Y qué puedes aconsejar a la gente para que no se encuentre con este tipo de problemas?
Alexander:
Los ejemplos fallidos incluyeron empresas que cambiaron sus prioridades y cancelaron proyectos. Cuando se encontraba en una buena etapa de preparación (de hecho, el MVP está listo), la empresa dijo: "Tenemos nuevas prioridades, estamos pasando a otro proyecto y estamos cerrando este".
No tuvimos ninguna falla global con los microservicios. Dormimos tranquilos, tenemos un turno de trabajo 24 horas al día, 7 días a la semana que da servicio a todo el BSS [sistema de soporte empresarial].
Y una cosa más: alquilamos microservicios de acuerdo con las reglas que se aplican a los productos en caja. La clave del éxito es que, en primer lugar, es necesario formar un equipo que prepare completamente el microservicio para la producción. El desarrollo en sí es, condicionalmente, del 40%. El resto es análisis, metodología DevSecOps, las integraciones adecuadas y la arquitectura adecuada. Prestamos especial atención a los principios de creación de aplicaciones seguras. En cada proyecto participan representantes de seguridad de la información tanto en la etapa de planificación de la arquitectura como durante el proceso de implementación. También gestionan sistemas para analizar código en busca de vulnerabilidades.
Digamos que implementamos nuestros servicios sin estado: los tenemos en Kubernetes. Esto permite que todos duerman tranquilos gracias al autoescalado y aumento automático de los servicios, y el turno de trabajo recoge incidentes.
En toda la existencia de nuestros microservicios solo ha habido una o dos incidencias que han llegado a nuestra línea. Ahora no hay problemas con el funcionamiento. Por supuesto, no tenemos 200, sino unos 50 microservicios, pero se utilizan en productos emblemáticos. Si fallaran, seríamos los primeros en enterarnos.
Microservicios y RRHH
Sergey:
Estoy de acuerdo con mi colega en cuanto a la transferencia al soporte: el trabajo debe organizarse correctamente. Pero les contaré los problemas que, por supuesto, existen.
En primer lugar, la tecnología es nueva. Esto es una exageración en el buen sentido, y encontrar un especialista que comprenda y pueda crear esto es un gran desafío. La competencia por los recursos es una locura, por lo que los expertos valen su peso en oro.
En segundo lugar, con la creación de determinados paisajes y un número creciente de servicios, el problema de la reutilización debe resolverse constantemente. Como les gusta hacer a los desarrolladores: "Escribamos muchas cosas interesantes aquí ahora..." Debido a esto, el sistema crece y pierde su efectividad en términos de dinero, costo de propiedad, etc. Es decir, es necesario incluir la reutilización en la arquitectura del sistema, incluirla en la hoja de ruta para la introducción de servicios y transferir el legado a una nueva arquitectura.
Otro problema, aunque a su manera es bueno, es la competencia interna. "Oh, aquí han aparecido nuevos chicos de moda, hablan un nuevo idioma". La gente, por supuesto, es diferente. Hay quienes están acostumbrados a escribir en Java y quienes escriben y usan Docker y Kubernetes. Son personas completamente diferentes, hablan diferente, usan términos diferentes y a veces no se entienden. La capacidad o incapacidad de compartir prácticas y conocimientos, en este sentido, también es un problema.
Bueno, escalar recursos. “¡Genial, vámonos! Y ahora queremos más rápido, más. ¿Qué, no puedes? ¿No es posible entregar el doble en un año? ¿Y por qué?" Estos dolores de crecimiento probablemente sean estándar para muchas cosas, muchos enfoques, y puedes sentirlos.
Respecto al seguimiento. Me parece que los servicios o herramientas de monitoreo industrial ya están aprendiendo o son capaces de trabajar tanto con Docker como con Kubernetes en un modo diferente y no estándar. Para que, por ejemplo, no terminemos con 500 máquinas Java en las que se ejecuta todo esto, es decir, se agrega. Pero a estos productos todavía les falta madurez, tienen que pasar por esto. El tema es realmente nuevo, seguirá desarrollándose.
Dmitry:
Sí, muy interesante. Y esto se aplica a RR.HH. Quizás su proceso de RRHH y su marca de RRHH hayan cambiado un poco durante estos 3 años. Empezaste a reclutar a otras personas con diferentes competencias. Y probablemente haya pros y contras. Anteriormente, la cadena de bloques y la ciencia de datos estaban de moda, y los especialistas en ellas valían millones. Ahora el costo está cayendo, el mercado se está saturando y hay una tendencia similar en los microservicios.
Sergey:
Sí, absolutamente.
Alexander:
RR.HH. hace la pregunta: "¿Dónde está tu unicornio rosa entre el backend y el frontend?" RRHH no entiende qué es un microservicio. Les contamos el secreto y les dijimos que el backend hizo todo y que no existe el unicornio. Pero RR.HH. está cambiando, aprendiendo rápidamente y contratando personas que tienen conocimientos básicos de TI.
La evolución de los microservicios
Dmitry:
Si nos fijamos en la arquitectura de destino, los microservicios parecen un monstruo. Su viaje duró varios años. Otros tienen un año, otros tres años. ¿Previó todos los problemas, la arquitectura de destino, cambió algo? Por ejemplo, en el caso de los microservicios, ahora vuelven a aparecer gateways y mallas de servicios. ¿Los usaste al principio o cambiaste la arquitectura misma? ¿Tiene tales desafíos?
Sergey:
Ya hemos reescrito varios protocolos de comunicación. Al principio había un protocolo, ahora cambiamos a otro. Aumentamos la seguridad y la confiabilidad. Comenzamos con tecnologías empresariales: Oracle, Web Logic. Ahora nos estamos alejando de los productos empresariales tecnológicos en microservicios y pasando a tecnologías de código abierto o completamente abiertas. Abandonamos las bases de datos y pasamos a lo que nos funciona más eficazmente en este modelo. Ya no necesitamos las tecnologías de Oracle.
Empezamos simplemente como un servicio, sin pensar en cuánto necesitábamos un caché, qué haríamos cuando no hubiera conexión con un microservicio, pero se necesitaran datos, etc. Ahora estamos desarrollando una plataforma para que se pueda describir la arquitectura. no en el lenguaje de los servicios, sino en el lenguaje empresarial, llevar la lógica empresarial al siguiente nivel cuando empecemos a hablar con palabras. Ahora hemos aprendido a hablar con letras, y el siguiente nivel es cuando los servicios se agruparán en algún tipo de agregado, cuando esto ya sea una palabra, por ejemplo, una ficha de producto completa. Está ensamblado a partir de microservicios, pero es una API construida sobre esto.
La seguridad es muy importante. Tan pronto como empiezas a ser accesible y tienes un servicio a través del cual puedes conseguir muchas cosas interesantes, y muy rápidamente, en una fracción de segundo, entonces surge el deseo de conseguirlo de una forma que no es la más segura. Para salir de esto, tuvimos que cambiar los enfoques de prueba y monitoreo. Tuvimos que cambiar el equipo, la estructura de gestión de entrega, CI/CD.
Se trata de una evolución, como ocurre con los teléfonos, sólo que mucho más rápido: primero aparecieron los teléfonos con pulsador, luego aparecieron los teléfonos inteligentes. Reescribieron y rediseñaron el producto porque el mercado tenía una necesidad diferente. Así evolucionamos: primer grado, décimo grado, trabajo.
De forma iterativa, por año se presenta algo desde el punto de vista de la tecnología, algo más desde el punto de vista del trabajo atrasado y las necesidades. Conectamos una cosa con otra. El equipo gasta el 20% en deuda técnica y soporte técnico para el equipo, el 80% en la entidad comercial. Y avanzamos entendiendo por qué lo estamos haciendo, por qué estamos haciendo estas mejoras tecnológicas y a qué conducirán. Como eso.
Dmitry:
Fresco. ¿Qué hay en Megafon?
Alexander:
El principal desafío cuando llegamos a los microservicios fue no caer en el caos. El estudio de arquitectura MegaFon se unió inmediatamente a nosotros, incluso se convirtió en nuestro iniciador y conductor; ahora tenemos una arquitectura muy sólida. Su tarea era comprender a qué modelo objetivo nos dirigimos y qué tecnologías debemos poner a prueba. En el caso de la arquitectura, realizamos estos pilotos nosotros mismos.
La siguiente pregunta fue: “¿Cómo explotar entonces todo esto?” Y uno más: “¿Cómo garantizar una interacción transparente entre microservicios?” La malla de servicio nos ayudó a responder la última pregunta. Probamos Istio y nos gustaron los resultados. Ahora estamos en la etapa de implantación en zonas productivas. Tenemos una actitud positiva ante todos los desafíos: el hecho de que necesitamos cambiar constantemente la pila y aprender algo nuevo. Estamos interesados en desarrollar, no en explotar soluciones antiguas.
Dmitry:
¡Palabras de oro! Estos desafíos mantienen alerta al equipo y a la empresa y crean el futuro. El RGPD creó directores de protección de datos y los desafíos actuales crean directores de arquitectura y microservicios. Y agrada.
Discutimos mucho. Lo principal es que un buen diseño de los microservicios y de la propia arquitectura permite evitar muchos errores. Por supuesto, el proceso es iterativo y evolutivo, pero es el futuro.
¡Gracias a todos los participantes, gracias a Sergei y Alexander!
Preguntas de la audiencia
Pregunta de la audiencia (1):
Sergey, ¿cómo ha cambiado la gestión de TI en tu empresa? Entiendo que cuando hay un stack grande de varios sistemas, cómo se gestiona es un proceso bastante claro y lógico. ¿Cómo reconstruyeron la gestión del componente de TI después de que se integraron una gran cantidad de microservicios en tan poco tiempo?
Sergey:
Estoy de acuerdo con mi colega en que la arquitectura es muy importante como motor de cambio. Empezamos teniendo una división de arquitectura. Los arquitectos son simultáneamente los dueños de la distribución de la funcionalidad y de los requisitos de cómo aparecerá en el paisaje. Por lo que también actúan como coordinadores de estos cambios. Como resultado, hubo cambios específicos en un proceso de entrega específico cuando creamos una plataforma CI/CD.
Pero los principios básicos estándar de desarrollo, análisis comercial, pruebas y desarrollo no han sido cancelados. Simplemente agregamos velocidad. Anteriormente, el ciclo requería mucho, pero la instalación en entornos de prueba requería mucho más. Ahora las empresas ven el beneficio y dicen: “¿Por qué no podemos hacer lo mismo en otros lugares?”
Es como, en el buen sentido, una inyección en forma de vacuna que demostró: puedes hacerlo de esta manera, pero puedes hacerlo de otra manera. Por supuesto que hay un problema de personal, de competencias, de conocimientos, de resistencias.
Pregunta de la audiencia (2):
Los críticos de la arquitectura de microservicios dicen que las pruebas y el desarrollo son difíciles. Esto es lógico cuando las cosas se complican. ¿Qué desafíos enfrentó su equipo y cómo los superó? Pregunta para todos.
Alexander:
Existen dificultades al pasar de microservicios a una plataforma, pero se pueden solucionar.
Por ejemplo, estamos creando un producto que consta de 5 a 7 microservicios. Necesitamos proporcionar pruebas de integración en toda la pila de microservicios para dar luz verde para pasar a la rama maestra. Esta tarea no era nueva para nosotros: ya llevábamos mucho tiempo haciéndola en BSS, cuando el proveedor nos proporcionó soluciones ya enviadas.
Y nuestro problema está sólo en el equipo pequeño. Se necesita un ingeniero de control de calidad para un producto condicional. Y así, enviamos un producto de 5 a 7 microservicios, de los cuales 2 a 3 pueden ser desarrollados por terceros. Por ejemplo, tenemos un producto en cuyo desarrollo participan nuestro proveedor de sistemas de facturación, Mail.ru Group y MegaFon R&D. Necesitamos cubrir esto con pruebas antes de enviarlo a producción. El ingeniero de calidad lleva mes y medio trabajando en este producto y el resto del equipo se queda sin su apoyo.
Esta complejidad sólo se debe al escalamiento. Entendemos que los microservicios no pueden existir en el vacío; el aislamiento absoluto no existe. Al cambiar un servicio, siempre intentamos preservar el contrato API. Si algo cambia debajo del capó, el servicio delantero permanece. Si los cambios son fatales, se produce algún tipo de transformación arquitectónica y pasamos a un metamodelo de datos completamente diferente, que es completamente incompatible; solo entonces hablamos de que aparece la especificación API del servicio v2. Admitimos la primera y la segunda versión simultáneamente y, después de que todos los consumidores cambien a la segunda versión, simplemente cerramos la primera.
Sergey:
Quiero agregar. Estoy absolutamente de acuerdo con las complicaciones: ocurren. El panorama se está volviendo más complejo y los costos generales están aumentando, especialmente para las pruebas. Cómo lidiar con esto: cambie a pruebas automatizadas. Sí, tendrá que invertir adicionalmente en escribir pruebas automáticas y pruebas unitarias. Para que los desarrolladores no pudieran comprometerse sin pasar la prueba, no podían cambiar el código. De modo que ni siquiera el pulsador funciona sin autotest, prueba unitaria.
Es importante mantener la funcionalidad anterior y esto supone una sobrecarga adicional. Si reescribe una tecnología en otro protocolo, la reescribe hasta cerrar todo por completo.
A veces no hacemos pruebas de un extremo a otro a propósito, porque no queremos detener el desarrollo, aunque también tenemos una cosa tras otra. El paisaje es muy grande, complejo, hay muchos sistemas. A veces son solo trozos; sí, al reducir el margen de seguridad, aparecen más riesgos. Pero al mismo tiempo liberas el suministro.
Alexander:
Sí, las pruebas automáticas y las pruebas unitarias le permiten crear un servicio de alta calidad. Estamos a favor de un oleoducto que no se puede pasar sin pruebas unitarias y de integración. A menudo tenemos que arrastrar emuladores y sistemas comerciales a zonas de prueba y entornos de desarrollo, porque no todos los sistemas se pueden colocar en zonas de prueba. Además, no se mojan simplemente: generamos una respuesta completa del sistema. Esta es una parte importante del trabajo con microservicios y también estamos invirtiendo en ello. Sin esto, sobrevendrá el caos.
Pregunta de la audiencia (3):
Según tengo entendido, los microservicios surgieron inicialmente de un equipo separado y ahora existen en este modelo. ¿Cuáles son sus pros y sus contras?
Simplemente tenemos una historia similar: surgió una especie de fábrica de microservicios. Ahora hemos llegado conceptualmente al punto en que estamos extendiendo este enfoque a la producción por flujos y sistemas. En otras palabras, nos estamos alejando del desarrollo centralizado de microservicios, modelos de microservicios y nos acercamos a los sistemas.
En consecuencia, nuestra operación también va a los sistemas, es decir, estamos descentralizando este tema. ¿Cuál es su enfoque y cuál es su historia objetivo?
Alexander:
Se te salió de la boca el nombre “fábrica de microservicios”: nosotros también queremos escalar. En primer lugar, ahora realmente tenemos un equipo. Queremos brindarles a todos los equipos de desarrollo que tiene MegaFon la oportunidad de trabajar en un ecosistema común. No queremos apoderarnos por completo de toda la funcionalidad de desarrollo que tenemos ahora. La tarea local es escalar, la tarea global es liderar el desarrollo de todos los equipos en la capa de microservicios.
Sergey:
Te diré el camino que hemos tomado. Realmente empezamos a trabajar como un solo equipo, pero ahora no estamos solos. Soy partidario de lo siguiente: debe haber un dueño del proceso. Alguien necesita comprender, gestionar, controlar y construir el proceso de desarrollo de microservicios. Debe poseer recursos y participar en la gestión de recursos.
Estos recursos, que conocen tecnologías, detalles y entienden cómo crear microservicios, pueden ubicarse en equipos de productos. Tenemos una combinación en la que las personas de la plataforma de microservicios están en el equipo de producto que crea la aplicación móvil. Están ahí, pero trabajan según el proceso del departamento de gestión de plataformas de microservicios con su director de desarrollo. Dentro de esta división hay un equipo independiente que se ocupa de la tecnología. Es decir, mezclamos un conjunto común de recursos entre nosotros y los dividimos entregándolos a los equipos.
Al mismo tiempo, el proceso sigue siendo general, controlado, avanza de acuerdo con principios tecnológicos generales, con pruebas unitarias, etc., todo lo que se construye encima. Puede haber columnas en forma de recursos recopilados de diferentes departamentos del enfoque del producto.
Alexander:
Sergey, en realidad eres el dueño del proceso, ¿verdad? ¿Se comparte la acumulación de tareas? ¿Quién es responsable de su distribución?
Sergey:
Mira: aquí está la mezcla otra vez. Hay un retraso que se forma en función de las mejoras tecnológicas; esta es una historia. Hay un backlog, que se formula a partir de proyectos, y hay un backlog de productos. Pero la secuencia de introducción en cada uno de los productos del servicio o la creación de este servicio la desarrolla un especialista del producto. No está en la dirección de TI, fue destituido especialmente de ella. Pero mi gente definitivamente trabaja según el mismo proceso.
El propietario del atraso en diferentes direcciones (el atraso de cambios) serán personas diferentes. La conexión de los servicios tecnológicos, su principio organizativo: todo esto estará en TI. Soy dueño de la plataforma y de los recursos también. En la cima está lo que concierne al backlog y los cambios funcionales, y la arquitectura en este sentido.
Digamos que una empresa dice: "Queremos esta función, queremos crear un nuevo producto, rehacer un préstamo". Respondemos: "Sí, lo reharemos". Los arquitectos dicen: "Pensemos: ¿en qué parte del préstamo escribiremos microservicios y cómo lo haremos?" Luego lo dividimos en proyectos, productos o una pila de tecnología, lo agrupamos en equipos y lo implementamos. ¿Ha creado un producto internamente y decidió utilizar microservicios en este producto? Decimos: "Ahora los sistemas heredados que teníamos, o los sistemas de primera línea, deben cambiar a estos microservicios". Los arquitectos dicen: “Entonces: en el retraso tecnológico dentro de los productos de primera línea: la transición a los microservicios. Ir". Y los especialistas en productos o propietarios de empresas entienden cuánta capacidad se asigna, cuándo se hará y por qué.
El final de la discusión, pero no todo.
Se organizó la conferencia mailto:CLOUD .
También organizamos otros eventos, p. Reunión @Kubernetes, donde siempre estamos buscando grandes oradores:
- Sigue a @Kubernetes y otras novedades de @Meetup en nuestro canal de Telegram
- ¿Interesado en hablar en uno de los @Meetups? Deja una solicitud para
Fuente: habr.com