El 25 de abril, en Mail.ru Group celebramos una conferencia sobre nubes y sus alrededores -
mailto: CLOUD . Algunos puntos destacados:
- Los principales proveedores rusos se reunieron en una etapa: Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center y Yandex.Cloud habló sobre los detalles de nuestro mercado en la nube y sus servicios;
- Los colegas de Bitrix24 contaron cómo llegaron a multiclaud ;
- Leroy Merlin, Otkrytie, Burger King y Schneider Electric proporcionaron una visión interesante por parte de los consumidores de la nube : qué tareas establece su negocio para TI y qué tecnologías, incluidas las de la nube, consideran las más prometedoras.
Todos los videos de la conferencia mailto: CLOUD se pueden ver
aquí , pero aquí puede leer cómo fue la discusión sobre microservicios. Alexander Deulin, jefe del centro de investigación y desarrollo de sistemas comerciales MegaFon, y Sergey Sergeyev, director de tecnología de la información del grupo M. Video-Eldorado, compartieron sus casos exitosos de deshacerse de los monolitos. También discutieron temas relacionados con la estrategia de TI, los procesos e incluso los recursos humanos.
Panelistas
- Sergey Sergeev , Director de Tecnología de la Información , M.Video-Eldorado Group ;
- Alexander Deulin , jefe del centro de investigación y desarrollo de sistemas comerciales MegaFon ;
- Moderador: Dmitry Lazarenko , jefe de PaaS-direction Mail.ru Cloud Solutions .
Después de un discurso de Alexander Deulin
"Cómo MegaFon expande su negocio a través de una plataforma de microservicios", Sergey Sergeev de M.Video-Eldorado se une a él para debate y moderador de la discusión Dmitry Lazarenko, Mail.ru Cloud Solutions.
A continuación, hemos preparado para usted una transcripción de la discusión, pero también puede ver el video:
Cambiar a microservicios: una respuesta a las necesidades del mercado
Dmitry:¿Ha tenido alguna experiencia exitosa al cambiar a microservicios? Y en general: ¿dónde ve el mayor beneficio en los negocios del uso de microservicios o la transición de monolitos a microservicios?
Sergey:Ya hemos avanzado 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 infinita de diferentes productos de primera línea con el back office. Y cada vez que teníamos que hacer integración adicional, desarrollo, implementación de nuestras reglas para la operación de un servicio.
En algún momento, nos dimos cuenta de que necesitábamos acelerar nuestros sistemas y la funcionalidad de salida. En ese momento, conceptos como microservicios, enfoque de microservicio ya existían en el mercado, y decidimos probarlo. Comenzó en 2016. Luego se instaló la plataforma y se implementaron los primeros 10 servicios, por un equipo separado.
Uno de los primeros servicios, el más cargado, fue un servicio de cálculo de precios. Cada vez que visita un canal, al grupo de empresas M.Video-Eldorado, ya sea un sitio web o una tienda minorista, recoge productos allí, ve el precio en el sitio web o en la "Cesta", un servicio calcula automáticamente el precio. Por qué esto es necesario: antes de eso, cada sistema tenía sus propios principios de trabajar con promociones: descuentos, etc. El back office se dedica a la fijación de precios, la funcionalidad de descuento se implementa en otro sistema. Era necesario centralizar y crear un servicio tan único y desmontable en forma de un proceso comercial que nos permitiera implementar esto. Así empezamos.
El valor de los primeros resultados fue muy bueno. En primer lugar, pudimos crear entidades desmontables que nos permiten trabajar por separado, agregadas. En segundo lugar, hemos reducido el costo de propiedad en términos de integración con una gran cantidad de sistemas.
En los últimos tres años, hemos agregado tres sistemas de primera línea. Fue difícil mantenerlos en la misma cantidad de recursos que la empresa podía permitirse. Por lo tanto, surgió la tarea de buscar nuevas salidas, respondiendo al mercado en términos de velocidad, en términos de costos internos y eficiencia.
Cómo evaluar el éxito de la transición a microservicios
Dmitry:¿Cómo se determina el éxito en el cambio a microservicios? ¿Cuál fue el "antes" en cada empresa? ¿Qué métrica usaste para determinar el éxito de la transición, quién realmente la determinó?
Sergey:En primer lugar, nació dentro de TI como habilitador: "desbloquear" nuevas funciones. Necesitábamos 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, la unificación de procesos entre ellos. Ahora es así, y en ese momento fue una oportunidad para crear una plataforma y confirmar la hipótesis de que podemos hacer esto, esto dará el efecto y el cálculo del caso de negocios.
AlejandroEl éxito es más bien una sensación interna. Las empresas siempre quieren más, y la profundidad de nuestra cartera de pedidos es la confirmación del éxito. Yo creo que si.
Sergey:Si, estoy de acuerdo. Durante tres años ya tenemos más de doscientos servicios y cartera de pedidos. La demanda de recursos dentro del equipo solo está creciendo, anualmente en un 30%. Esto se debe a que la gente sentía: es más rápido, de manera diferente, otras tecnologías, todo esto se está desarrollando.
Los microservicios vendrán, pero el núcleo permanecerá
Dmitry:Esto es como un proceso interminable en el que inviertes en desarrollo. ¿La transición a microservicios para empresas ya ha finalizado o no?
Sergey:Muy facil de responder. ¿Qué opinas: reemplazar teléfonos es un proceso interminable? Nosotros mismos compramos teléfonos todos los años. Y aquí está: si bien hay una necesidad de velocidad, en la adaptación al mercado, se requerirán algunos cambios. Esto no significa que rechacemos las cosas estándar.
Pero no podemos abrazar y rehacer todo de inmediato. Tenemos servicios de integración estándar heredados que existían antes de esto: autobuses empresariales, etc. Pero hay un retraso, y también hay una necesidad. La cantidad de aplicaciones móviles y su funcionalidad están creciendo. Al mismo tiempo, nadie dice que le darán un 30% más de dinero. Es decir, siempre hay necesidades, por un lado, y por otro, una búsqueda de eficiencia.
Dmitry:La vida está en buena forma.
(Risas)AlejandroEn general si. No tenemos enfoques revolucionarios para eliminar partes centrales del paisaje. Se está trabajando en forma sistemática para descomponer los sistemas de modo que sean más consistentes con la arquitectura de microservicios, para reducir la influencia de los sistemas entre sí.
Pero planeamos mantener la parte central, ya que en el panorama del operador siempre habrá algunas plataformas que compraremos. Una vez más, necesita un equilibrio saludable: no debemos apresurarnos hacia el núcleo de "corte". Ponemos los sistemas uno al lado del otro, y ahora, resulta que ya está en muchas partes centrales. Además, al desarrollar la funcionalidad, hacemos las representaciones necesarias para todos los canales que funcionan con nuestros servicios de comunicación.
Cómo vender microservicios a una empresa
Dmitry:Todavía estoy interesado, para aquellos que no han cambiado, pero van a: ¿qué tan fácil fue vender esta idea a las empresas y fue una apuesta, un proyecto de inversión? O fue una estrategia deliberada: ahora vamos a microservicios y eso es todo, nada nos detendrá. ¿Cómo te fue?
Sergey:No vendimos el enfoque, pero el negocio ganó. Hubo un problema en los negocios e intentamos eliminarlo. En ese momento, se expresó en el hecho de que en diferentes canales se utilizaron diferentes principios de fijación de precios, por separado para promociones, para acciones, etc. Fue difícil de mantener, surgieron errores, escuchamos las quejas de los clientes. Es decir, vendimos la eliminación del problema, pero vinimos con el hecho de que necesitamos dinero para crear una plataforma. Y mostraron un caso de negocios sobre el ejemplo de la primera etapa de inversión: cómo continuaremos pagándolo y qué nos permitirá hacer.
Dmitry:¿Has arreglado de alguna manera el tiempo de la primera etapa?
Sergey:Si por supuesto. Nos llevó 6 meses crear el núcleo como plataforma y pruebas piloto. Durante este tiempo, intentamos crear una plataforma en la que el piloto fuera patinado. Confirmaron aún más la hipótesis, y dado que funciona, entonces podemos continuar. Comenzaron a replicar y fortalecer al equipo; lo llevaron a una unidad separada, que solo se dedica a esto.
El siguiente es el trabajo sistemático que procede de las necesidades del negocio, las oportunidades, la disponibilidad de recursos y todo lo que ahora está en el trabajo.
Dmitry:Esta bien Alexander, ¿qué dices?
AlejandroNuestros microservicios nacieron de la "espuma marina", debido al ahorro de recursos, debido a algunos residuos en forma de capacidades del servidor y la redistribución de fuerzas dentro del equipo. Inicialmente, no vendimos este proyecto a empresas. Fue un proyecto donde ambos investigamos y desarrollamos en consecuencia. Comenzamos a principios de 2018 y desarrollamos con entusiasmo esta dirección. Las ventas acaban de comenzar y estamos en el proceso.
Dmitry:Pero sucede que una empresa le permite hacer esas cosas según el principio de Google, ¿en un día libre a la semana? ¿Tienes esa dirección?
AlejandroAl mismo tiempo que la investigación, estábamos involucrados en tareas comerciales, porque todos nuestros microservicios son soluciones a problemas comerciales. Solo al principio creamos microservicios que cubren una pequeña parte de la base de suscriptores, y ahora estamos en casi todos los productos estrella.
Y el impacto material ya está claro: ya podemos contarnos, podemos estimar la velocidad de salida del producto y la pérdida de ingresos si tuviéramos que seguir el camino anterior. Aquí es donde estamos construyendo el caso.
Microservicios: ¿exageración o necesidad?
Dmitry:Los números son números. Y los ingresos o el dinero ahorrado es muy importante. ¿Y si miras al otro lado? Parece que los microservicios son una tendencia, exageración y muchas empresas abusan de él? ¿Qué tan claramente distingue entre lo que traduce y lo que no traduce en microservicios? Si el legado es ahora, ¿lo seguirás teniendo en 5 años? ¿Cuál será la edad de los sistemas de información que funcionan en M. Video-Eldorado y MegaFon en 5 años? ¿Habrá sistemas de información de diez años, quince años o será una nueva generación? Como lo ves
Sergey:Me parece que muy lejos es difícil de hacer. Si mira hacia atrás, ¿quién sugirió que esto desarrollaría el mercado de la tecnología y el mismo aprendizaje automático, la identificación del usuario por la cara? Pero si nos fijamos en los próximos años, me parece que los sistemas centrales, los sistemas empresariales de la clase ERP en las empresas, han estado trabajando durante mucho tiempo.
Nuestras empresas han estado juntas durante 25 años, en ellas, el ERP clásico se encuentra muy profundo en el panorama del sistema. Está claro que sacamos algunas piezas de allí e intentamos agregarlas en microservicios, pero el núcleo permanecerá. Ahora me resulta difícil imaginar que reemplazaremos todos los sistemas centrales allí y pasamos rápidamente al otro lado brillante de los nuevos sistemas.
Soy partidario de que todo lo que está más cerca del cliente y del consumidor, donde existe el mayor beneficio y valor comercial, donde la adaptabilidad y el enfoque en la velocidad, en los cambios, en "intentar, cancelar, reutilizar, hacer otra cosa "- allí cambiará el paisaje. Y los productos de caja no están integrados muy bien allí. Al menos no vemos esto. Requiere las soluciones más livianas y simples.
Vemos tal desarrollo:
- sistemas centrales de información (principalmente back office);
- las capas intermedias en forma de microservicios conectan el núcleo, el agregado, crean un caché, etc.
- los sistemas de primera línea están dirigidos al consumidor;
- capa de integración, que generalmente se integra en los mercados, otros sistemas y ecosistemas. Esta capa es lo más ligera posible, simple, con un mínimo de lógica de negocios.
Pero al mismo tiempo, soy partidario de seguir usando los viejos principios, si están acostumbrados al lugar.
Digamos que tiene un sistema empresarial clásico. Se encuentra en el paisaje de un proveedor, 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 la oficina administrativa, de los cuales se recopilan piezas de información en el proceso comercial, que luego son utilizados por los sistemas front-end 8-10, los beneficios se notan de inmediato. Saca de cinco sistemas de back-office, crea un servicio, además, aislado, que se centra en el proceso de negocio. Usted hace que un servicio sea tecnológico, para que almacene información en caché y sea tolerante a fallas, y también trabaje con documentos o entidades comerciales. E intégrelo en un solo principio con todos los productos de primera línea. Cancelaron el producto de primera línea, simplemente desactivaron la integración. Mañana necesita escribir una aplicación móvil o hacer un sitio pequeño y solo una parte para aterrizar en lo funcional: es simple: lo arma como un constructor. Veo más el desarrollo en esta dirección, al menos en nuestro país.
AlejandroSergey describió completamente nuestro enfoque, gracias. Solo diré a dónde definitivamente no iremos: a la parte central, al tema de la carga en línea. Es decir, la calificación y el cobro seguirán siendo, de hecho, una trilla "trilla" que amortizará el dinero de manera confiable. Y este sistema continuará siendo certificado por nuestras autoridades reguladoras. Todo lo demás que mira hacia los clientes, por supuesto, son microservicios.
Dmitry:Aquí la certificación es solo una historia. Probablemente más apoyo. Si gasta un poco en soporte o el sistema no requiere soporte y mejora, es mejor no tocarlo. Compromiso razonable.
Cómo desarrollar microservicios confiables
Dmitry:Bueno Pero aún estoy interesado. Ahora está contando una historia de éxito: todo estuvo bien, cambiamos a microservicios, defendimos la idea frente al negocio y todo funcionó. Pero escuché otras historias.
Hace un par de años, una empresa suiza, que invirtió dos años en el desarrollo de una nueva plataforma de microservicios para bancos, finalmente cerró este proyecto. Completamente plegado Se gastaron muchos millones de francos suizos, pero al final dispersaron al equipo, no fue así.
¿Has tenido historias similares? ¿Hubo o hay dificultades? Por ejemplo, mantenimiento de microservicios, el mismo monitoreo también es un dolor de cabeza en las operaciones de la compañía. Después de todo, el número de componentes aumenta decenas de veces. ¿Cómo ve esto? ¿Hubo ejemplos de inversiones fallidas aquí? ¿Y qué se puede aconsejar a las personas para que no encuentren problemas similares?
AlejandroEjemplos infructuosos fueron que el negocio cambió las prioridades y canceló proyectos. Cuando se encuentra en una buena etapa de preparación (MVP está realmente listo), la empresa dijo: "Tenemos nuevas prioridades, vamos a otro proyecto y estamos cerrando este".
No teníamos archivos globales con microservicios. Dormimos pacíficamente, tenemos un turno de servicio 24/7 que sirve a todo el BSS [sistema de apoyo comercial].
Y sin embargo, alquilamos microservicios de acuerdo con las reglas por las cuales se alquilan los productos en caja. La clave del éxito es que, en primer lugar, debe formar un equipo que prepare completamente el microservicio para la producción. El desarrollo en sí es, condicionalmente, 40%. El resto es análisis, metodología DevSecOps, las integraciones correctas y la arquitectura correcta. Prestamos especial atención a los principios de creación de aplicaciones seguras. En cada proyecto, los representantes de la seguridad de la información participan tanto en la etapa de planificación de la arquitectura como en el proceso de implementación. También gestionan sistemas de análisis de código para vulnerabilidades.
Supongamos que desplegamos nuestros servicios sin estado: los tenemos en Kubernetes. Esto permite que todos duerman pacíficamente debido a los servicios de autoescalado y aumento automático, y el cambio en el servicio recoge los incidentes.
Durante todo el tiempo de existencia de nuestros microservicios, solo hubo uno o dos incidentes que llegaron a nuestra línea. Ahora no hay problemas operativos. Por supuesto, no tenemos 200, sino unos 50 microservicios, pero se utilizan en productos emblemáticos. Si fallaban, seríamos los primeros en saberlo.
Microservicios y RRHH
Sergey:Estoy de acuerdo con mi colega acerca de la transferencia de soporte, que necesita organizar el trabajo correctamente. Pero diré sobre los problemas, que, por supuesto, son.
En primer lugar, la tecnología es nueva. Esto es una exageración en el buen sentido, y encontrar un especialista que lo entienda y pueda crearlo es un gran desafío. La competencia por los recursos es una locura, respectivamente, los expertos valen su peso en oro.
En segundo lugar, al crear ciertos paisajes y un número creciente de servicios, el problema de la reutilización debe resolverse constantemente. Como a los desarrolladores les gusta hacer: "Vamos a escribir aquí muchas cosas interesantes aquí ..." Debido a esto, el sistema crece y pierde su efectividad en términos de dinero, costo de propiedad, etc. Es decir, debe reutilizar en la arquitectura de los sistemas, incluir en la hoja de ruta la introducción de servicios y la transferencia del legado a la nueva arquitectura.
Otro problema, aunque es bueno a su manera, es la competencia interna. "Oh, han aparecido nuevos tipos de moda aquí, hablan un nuevo idioma". Las personas, por supuesto, son diferentes. Hay quienes están acostumbrados a escribir en Java, y quienes escriben y usan Docker y Kubernetes. Estas son personas completamente diferentes, hablan de manera diferente, usan términos diferentes y algunas veces no se entienden entre sí. La capacidad o la incapacidad de compartir prácticas, compartir conocimientos, en este sentido, también es un problema.
Bueno, escalando recursos. “¡Genial, vamos! Y ahora queremos más rápido, más. ¿No puedes? ¿Es imposible entregar el doble en un año? ¿Por qué? Tales problemas de crecimiento son estándar, probablemente por muchas cosas, muchos enfoques, y se sienten.
Respecto al monitoreo. Me parece que los servicios o las herramientas de monitoreo industrial ya están aprendiendo o pueden trabajar con Docker y Kubernetes en un modo diferente y no estándar. Para que, por ejemplo, no tenga 500 máquinas Java en las que se está ejecutando todo esto, es decir, agregados. Pero estos productos aún carecen de madurez, tienen que pasar por esto. El tema es realmente nuevo, aún se desarrollará.
Dmitry:Si muy interesante. Y esto se aplica a los recursos humanos. Quizás su proceso de RR.HH. y su marca de RR.HH. hayan cambiado un poco durante estos 3 años. Comenzaste a reclutar a otras personas con una competencia diferente. Y probablemente hay pros y contras. Anteriormente, blockchain y la ciencia de datos eran de alta tecnología, y los especialistas en ellos valían solo millones. Ahora el precio está cayendo, el mercado está saturado y existe una tendencia similar en los microservicios.
Sergey:Si absolutamente.
AlejandroHR hace la pregunta: "¿Dónde está tu unicornio rosa entre el backend y la interfaz?" RRHH no entiende qué es el microservicio. Les revelamos un secreto y les dijimos que este backend hizo todo, y que no hay unicornio. Pero RR.HH. está cambiando, rápidamente aprende y recluta personas que poseen conocimientos básicos de TI.
La evolución de los microservicios.
Dmitry:Si observa la arquitectura de destino, los microservicios se ven como un monstruo. Tu viaje tomó varios años. Otros tienen un año, otros tienen tres años. Previste todos los problemas, la arquitectura de destino, ¿cambió algo? Por ejemplo, en el caso de microservicios, puertas de enlace, las mallas de servicio ahora aparecen nuevamente. ¿Los usó al principio o cambió la arquitectura misma? ¿Tienes algún desafío?
Sergey:Ya hemos reescrito varios protocolos de interacción. Inicialmente, un protocolo, ahora cambió a otro. Aumentamos la seguridad y la fiabilidad. Comenzamos con tecnología empresarial: Oracle, Web Logic. Ahora nos estamos alejando de los productos empresariales tecnológicos en microservicios y pasándonos a código abierto o a tecnologías completamente abiertas. Abandonamos las bases de datos, pasamos a lo que funciona más eficientemente para nosotros en este modelo. Ya no necesitamos las tecnologías de Oracle.
, , , , , , . . , , -, - , . , — - , — , . , API.
. , , , , . , . , , CI/CD.
— , : , . , , . : , , .
- , - — backlog' . . 20% , 80% — -. , , , , . .
:. «»?
:— . , «» — . , . .
: « ?». : « ?». service mesh. Istio, . . — , , - . , .
:! . GDPR chief data protection officers, . .
. — . , , .
, !
(1):, IT- ? , , — . IT- , ?
:, . , . , . . , CI/CD.
, , -, — . . -, — -. : « ?».
, , , : , -. , , , , .
(2):, . , - . ? .
:, .
, , 5-7 . , -. : BSS, .
. QA-. , 5-7 , 2-3 . , , , Mail.ru Group R&D «». , . QA- , .
. , , . , API-. - , front . , - , — , API- v2. , .
:. — . , , . : . , unit-. , . push , unit-.
, . , , .
end-to-end , , . , , . — , , . .
:, unit- . , unit- . , , . — . , . .
(3):, . ?
: . , . , , , .
, , . ?
:« » — . -, . , «», . , . — , — .
:, . , . : . - , , . -.
, , , , . , , . , . , . , .
, , , unit- — , . , .
:, , ? Backlog ? ?
:: . backlog, , — . backlog, , backlog . . IT-, . .
backlog' — backlog' — . , — IT. , — . , backlog' , .
, : « , — ». : «, ». : « : ?». , , . ? : « legacy-, , , ». : «: backlog — . ». , capacity, .
,
La conferencia mailto: CLOUD fue alojada por Mail.ru Cloud Solutions .También hacemos otros eventos, por ejemplo, @Kubernetes Meetup , donde siempre buscamos oradores geniales:- Siga las noticias de @Kubernetes y otras @Meetup en nuestro canal de Telegram t.me/k8s_mail
- ¿Quieres hablar en uno de @Meetup? Deje una solicitud en mcs.mail.ru/speak