O 25 de abril, en Mail.ru Group realizamos unha conferencia sobre as nubes e arredor de... . Algúns aspectos destacados:
- O principal — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center e Yandex.Cloud falaron sobre as particularidades do noso mercado na nube e os seus servizos;
- Os compañeiros de Bitrix24 contaron como eles ;
- Leroy Merlin, Otkritie, Burger King e Schneider Electric proporcionaron interesantes — que tarefas establece a súa empresa para a TI e que tecnoloxías, incluídas as de nube, consideran as máis prometedoras.
Podes ver todos os vídeos da conferencia mailto:CLOUD , e aquí podes ler como foi a discusión sobre os microservizos. Alexander Deulin, xefe do centro de investigación e desenvolvemento de sistemas empresariais MegaFon, e Sergey Sergeev, director de tecnoloxía da información do grupo M.Video-Eldorado, compartiron os seus casos exitosos de desfacerse dos monolitos. Tamén falamos de cuestións relacionadas coa estratexia de TI, os procesos e mesmo en RRHH.
Panelistas
- Sergey Sergeev, CIO do grupo "M.Video-Eldorado";
- Alexandre Deulin, xefe do centro de investigación e desenvolvemento de sistemas empresariais MegaFon;
- Moderador - Dmitri Lazarenko, Xefe de dirección PaaS Solucións na nube Mail.ru.
Despois do discurso de Alexander Deulin Súmase para a discusión Sergey Sergeev de M.Video-Eldorado e o moderador de discusión Dmitry Lazarenko, Mail.ru Cloud Solutions.
A continuación preparámosche unha transcrición do debate, pero tamén podes ver o vídeo:
A transición aos microservizos é unha resposta ás necesidades do mercado
Dimitri:
Tivo algunha experiencia exitosa coa migración a microservizos? E en xeral: onde ves o maior beneficio empresarial do uso de microservizos ou do paso dos monolitos aos microservizos?
Sergey:
Xa percorremos algún camiño na transición aos microservizos e levamos máis de tres anos utilizando este enfoque. A primeira necesidade que xustificaba a necesidade de microservizos foi a integración infinita de varios produtos front-end co back office. E cada vez vímonos obrigados a facer unha integración e desenvolvemento adicional, implementando as nosas propias regras para o funcionamento deste ou aquel servizo.
Nalgún momento, decatámonos de que necesitabamos acelerar o funcionamento dos nosos sistemas e a saída da funcionalidade. Nese momento xa existían no mercado conceptos como microservizos e un enfoque de microservizos, e decidimos probalo. Isto comezou en 2016. Despois colocouse a plataforma e os primeiros 10 servizos foron implementados por un equipo separado.
Un dos primeiros servizos, o máis cargado, foi o servizo de cálculo de prezos. Cada vez que chegas a calquera canle, ao grupo de empresas M.Video-Eldorado, xa sexa unha páxina web ou unha tenda de venda polo miúdo, selecciona alí un produto, consulta o prezo na páxina web ou na “Cesta”, o custo é automaticamente calculado por un servizo. Por que é necesario: antes, cada sistema tiña os seus propios principios para traballar con promocións, con descontos, etc. O noso back office xestiona os prezos; a funcionalidade de desconto está implementada noutro sistema. Isto debía centralizarse e crear un servizo único e separable en forma de proceso empresarial que nos permitise implementar isto. Así foi como comezamos.
O valor dos primeiros resultados foi moi grande. En primeiro lugar, puidemos crear entidades separables que nos permiten traballar por separado e de forma agregada. En segundo lugar, reducimos o custo de propiedade en termos de integración con máis sistemas.
Durante os últimos tres anos, engadimos tres sistemas de primeira liña. Era difícil mantelos coa mesma cantidade de recursos que podía permitirse a empresa. Por iso, xurdiu a tarefa de buscar novas saídas, respondendo ao mercado en termos de rapidez, en canto a custos internos e eficiencia.
Como medir o éxito da migración a microservizos
Dimitri:
Como se determina o éxito na migración aos microservizos? Cal era o "antes" en cada empresa? Que métrica utilizou para determinar o éxito da transición e quen a determinou realmente?
Sergey:
En primeiro lugar, naceu dentro das TI como un habilitador: "desbloquear" novas capacidades. Tiñamos a necesidade de facelo todo máis rápido por relativamente o mesmo diñeiro, respondendo aos desafíos do mercado. Agora o éxito exprésase na cantidade de servizos reutilizados por diferentes sistemas, unificación de procesos entre si. Agora si, pero nese momento era unha oportunidade para crear unha plataforma e confirmar a hipótese de que podemos facelo, dará efecto e calculará o caso de negocio.
Alexandre:
O éxito é máis ben un sentimento interno. As empresas sempre queren máis, e a profundidade do noso atraso é unha proba de éxito. A min paréceme así.
Sergey:
Si, estou de acordo. En tres anos xa temos máis de douscentos servizos e atraso. A necesidade de recursos dentro do equipo só está a medrar, nun 30% anual. Isto ocorre porque a xente sentía: é máis rápido, é diferente, hai tecnoloxías diferentes, todo isto estase desenvolvendo.
Os microservizos virán, pero o núcleo permanecerá
Dimitri:
É como un proceso interminable no que se inviste no desenvolvemento. A transición aos microservizos para empresas xa rematou ou non?
Sergey:
É moi doado responder. Que pensas: substituír teléfonos é un proceso interminable? Nós mesmos mercamos teléfonos todos os anos. E aquí está: mentres haxa necesidade de celeridade, de adaptación ao mercado, serán necesarios algúns cambios. Isto non significa que abandonemos as cousas estándar.
Pero non podemos cubrir e refacer todo á vez. Temos servizos de integración estándar legados que existían antes: autobuses empresariais, etc. Pero hai un atraso, e tamén hai unha necesidade. O número de aplicacións móbiles e a súa funcionalidade está crecendo. Ao mesmo tempo, ninguén di que se lle dará un 30% máis de diñeiro. É dicir, sempre hai necesidades por unha banda, e unha busca da eficiencia por outra.
Dimitri:
A vida está en boa forma. (Risas)
Alexandre:
En xeral, si. Non temos enfoques revolucionarios para eliminar a parte central da paisaxe. Está en marcha un traballo sistemático para descompoñer os sistemas para que sexan máis coherentes coa arquitectura de microservizos, para reducir a influencia dos sistemas entre si.
Pero pensamos manter a parte central, xa que no panorama do operador sempre haberá algunhas plataformas que merquemos. De novo, necesitamos un equilibrio saudable: non debemos precipitarnos en cortar o núcleo. Colocamos os sistemas un ao carón, e agora resulta que xa estamos enriba de moitas partes fundamentais. Ademais, desenvolvendo a funcionalidade, creamos as representacións necesarias para todas as canles que traballan cos nosos servizos de comunicación.
Como vender microservizos a empresas
Dimitri:
Tamén estou interesado - para aqueles que non cambiaron, pero están a planear: que tan fácil foi vender esta idea á empresa e foi unha aventura, un proxecto de investimento? Ou foi unha estratexia consciente: agora imos aos microservizos e xa está, nada nos para. Como foi para ti?
Sergey:
Non estabamos a vender un enfoque, senón un beneficio empresarial. Houbo un problema nos negocios, e intentamos solucionalo. Nese momento, expresouse no feito de que diferentes canles utilizaban diferentes principios para calcular os prezos: por separado para as promocións, para as promocións, etc. Foi difícil de manter, producíronse erros e escoitamos as queixas dos clientes. É dicir, estabamos vendendo unha solución a un problema, pero viñemos co feito de que necesitabamos cartos para crear unha plataforma. E mostraron un caso de negocio co exemplo da primeira etapa do investimento: como o seguiremos recuperando e que nos permitirá facer isto.
Dimitri:
Gravaches dalgún xeito o tempo da primeira etapa?
Sergey:
Si, seguro. Asignamos 6 meses para crear o núcleo como plataforma e probar o piloto. Durante este tempo, tentamos crear unha plataforma na que patinar o piloto. Despois confirmouse a hipótese, e como funciona, significa que podemos continuar. Comezaron a replicar e fortalecer o equipo: trasladárono a unha división separada que fai precisamente iso.
A continuación vén o traballo sistemático en función das necesidades empresariais, das oportunidades, da dispoñibilidade de recursos e de todo o que se está a traballar actualmente.
Dimitri:
OK. Alexandre, que dis?
Alexandre:
Os nosos microservizos naceron da “escuma do mar”, debido ao aforro de recursos, a algúns restos en forma de capacidade do servidor e á redistribución de forzas dentro do equipo. Inicialmente, non vendemos este proxecto á empresa. Este foi un proxecto no que ambos investigamos e desenvolvemos en consecuencia. Comezamos a principios de 2018 e simplemente desenvolvemos esta dirección con entusiasmo. As vendas acaban de comezar e estamos no proceso.
Dimitri:
Acontece que unha empresa che permite facer cousas como Google, nun día gratuíto á semana? Tes tal dirección?
Alexandre:
Ao mesmo tempo que a investigación, tamén tratamos problemas empresariais, polo que todos os nosos microservizos son solucións a problemas empresariais. Só ao principio construímos microservizos que cubrían unha pequena parte da base de subscritores, e agora estamos presentes en case todos os produtos emblemáticos.
E o impacto material xa está claro: xa podemos contar, a velocidade dos lanzamentos de produtos e a perda de ingresos pódese estimar se seguimos o camiño antigo. Isto é o que estamos a construír o caso.
Microservizos: bombo ou necesidade?
Dimitri:
Os números son números. E os ingresos ou o diñeiro aforrado son moi importantes. E se miras para o outro lado? Parece que os microservizos son unha tendencia, un bombo e moitas empresas están a abusar del? Con que claridade diferencias entre o que fas e o que non traduces a microservizos? Se o legado agora, seguirás tendo legado dentro de 5 anos? Cal será a idade dos sistemas de información que funcionan en M.Video-Eldorado e MegaFon en 5 anos? Haberá sistemas de información de dez, quince anos ou será unha nova xeración? Como ves isto?
Sergey:
Paréceme que é difícil pensar moi lonxe. Se botamos a vista atrás, quen imaxinaba que o mercado tecnolóxico se desenvolvería deste xeito, incluíndo a aprendizaxe automática e a identificación de usuarios por cara? Pero se miras aos próximos anos, paréceme que os sistemas básicos, os sistemas empresariais de clase ERP nas empresas, levan funcionando durante bastante tempo.
As nosas empresas teñen colectivamente 25 anos, cun ERP clásico moi profundo no panorama dos sistemas. Está claro que estamos sacando algunhas pezas de aí e tentando agregalas en microservizos, pero o núcleo permanecerá. Cústame agora imaxinar que substituiremos todos os sistemas básicos alí e pasaremos rapidamente ao outro lado brillante dos novos sistemas.
Son partidario de que todo o que está máis preto do cliente e do consumidor é onde está o maior beneficio e valor comercial, onde a adaptabilidade e o foco na velocidade, no cambio, no "probar, cancelar, reutilizar, facer algo diferente" están necesario “-aí é onde a paisaxe cambiará. E os produtos en caixa non encaixan moi ben alí. Polo menos non o vemos. Alí son necesarias as solucións máis sinxelas e sinxelas.
Vemos este desenvolvemento:
- sistemas de información básicos (principalmente back office);
- as capas intermedias en forma de microservizos conectan o núcleo, agregan, crean unha caché, etc.
- os sistemas de primeira liña están dirixidos ao consumidor;
- unha capa de integración que xeralmente se integra en mercados, outros sistemas e ecosistemas. Esta capa é o máis lixeira posible, sinxela e contén un mínimo de lóxica empresarial.
Pero ao mesmo tempo, son partidario de seguir empregando os vellos principios se se usan adecuadamente.
Digamos que tes un sistema empresarial clásico. Está situado na paisaxe dun provedor e consta de dous módulos que funcionan entre si. Tamén hai unha interface de integración estándar. Por que refacelo e traer alí un microservizo?
Pero cando hai 5 módulos no back office, a partir dos cales se recollen pezas de información nun proceso empresarial, que logo é usada por 8-10 sistemas de primeira liña, o beneficio é inmediatamente perceptible. Tomas de cinco sistemas de back-office e creas un servizo, un illado, centrado no proceso empresarial. Fai que o servizo sexa tecnoloxicamente avanzado, de xeito que almacena información na caché e sexa tolerante a fallos, e tamén funcione con documentos ou entidades comerciais. E intégraso segundo un único principio con todos os produtos de primeira liña. Cancelaron o produto de primeira liña, simplemente desactivaron a integración. Mañá cómpre escribir unha aplicación móbil ou facer un pequeno sitio web e poñer só unha parte na funcionalidade: todo é sinxelo: montaches como un construtor. Vexo máis desenvolvemento nesta dirección, polo menos no noso país.
Alexandre:
Sergey describiu completamente o noso enfoque, grazas. Só direi a onde definitivamente non imos: á parte central, ao tema da facturación en liña. É dicir, a clasificación e a carga seguirán sendo, de feito, un "gran" trillador que eliminará o diñeiro de forma fiable. E este sistema seguirá sendo certificado polas nosas autoridades reguladoras. Todo o que mira cara aos clientes, por suposto, son microservizos.
Dimitri:
Aquí a certificación é unha historia. Probablemente máis apoio. Se gastas pouco en soporte ou o sistema non require soporte e modificación, é mellor non tocalo. Un compromiso razoable.
Como desenvolver microservizos fiables
Dimitri:
Ben. Pero aínda estou interesado. Agora estás contando unha historia de éxito: todo estivo ben, cambiamos aos microservizos, defendemos a idea ao negocio e todo funcionou. Pero escoitei outras historias.
Hai un par de anos, unha empresa suíza que investira dous anos no desenvolvemento dunha nova plataforma de microservizos para bancos acabou por pechar o proxecto. Completamente colapsado. Gastáronse moitos millóns de francos suízos e, ao final, o equipo dispersouse - non funcionou.
Tiveches historias similares? Houbo ou houbo dificultades? Por exemplo, manter microservizos e vixilancia tamén é un quebradizo de cabeza nas actividades operativas da empresa. Despois de todo, o número de compoñentes aumenta decenas de veces. Como o ves, houbo exemplos de investimentos infrutuosos aquí? E que podes aconsellar á xente para que non se atopen con este tipo de problemas?
Alexandre:
Exemplos sen éxito incluíron empresas que cambiaron prioridades e cancelaron proxectos. Cando se atopaba nunha boa fase de preparación (de feito, o MVP está listo), a empresa dixo: "Temos novas prioridades, pasamos a outro proxecto e estamos pechando este".
Non tivemos ningún fallo global cos microservizos. Durmimos tranquilos, temos unha quenda de servizo 24 horas ao día, os 7 días do día, que dá servizo a todo o BSS [sistema de apoio comercial].
E unha cousa máis: alugamos microservizos segundo as regras que se aplican aos produtos en caixa. A clave do éxito é que necesitas, en primeiro lugar, montar un equipo que prepare completamente o microservizo para a produción. O desenvolvemento en si é, condicionalmente, do 40%. O resto son analíticas, metodoloxía DevSecOps, as integracións correctas e a arquitectura adecuada. Prestamos especial atención aos principios de creación de aplicacións seguras. Os representantes da seguridade da información participan en cada proxecto tanto na fase de planificación da arquitectura como durante o proceso de implantación. Tamén xestionan sistemas de análise de código para detectar vulnerabilidades.
Digamos que implementamos os nosos servizos sen estado: témolos en Kubernetes. Isto permite que todos durman tranquilos debido á escala automática e ao aumento automático dos servizos, e a quenda de servizo recolle os incidentes.
En toda a existencia dos nosos microservizos, só houbo unha ou dúas incidencias que chegaron á nosa liña. Agora non hai problemas co funcionamento. Nós, por suposto, non temos 200, senón uns 50 microservizos, pero utilízanse en produtos emblemáticos. Se fallasen, seríamos os primeiros en saber diso.
Microservizos e RRHH
Sergey:
Estou de acordo co meu compañeiro sobre o traslado ao apoio - que o traballo debe organizarse correctamente. Pero vouvos falar dos problemas que, por suposto, existen.
En primeiro lugar, a tecnoloxía é nova. Esta é unha exageración no bo sentido, e atopar un especialista que entenda e poida crear isto é un gran desafío. A competencia polos recursos é tola, polo que os expertos valen o seu peso en ouro.
En segundo lugar, coa creación de determinadas paisaxes e un número crecente de servizos, o problema da reutilización debe ser solucionado constantemente. Como lles gusta facer aos desenvolvedores: "Escribamos moitas cousas interesantes aquí agora..." Por iso, o sistema crece e perde a súa eficacia en termos de diñeiro, custo de propiedade, etc. É dicir, é necesario incluír a reutilización na arquitectura do sistema, incluíla na folla de ruta para introducir servizos e transferir o legado a unha nova arquitectura.
Outro problema -aínda que isto é bo ao seu xeito- é a competencia interna. "Oh, apareceron novos mozos de moda aquí, falan un novo idioma". A xente, por suposto, é diferente. Hai quen está afeito a escribir en Java, e quen escribe e usa Docker e Kubernetes. Son persoas completamente diferentes, falan de xeito diferente, usan termos diferentes e ás veces non se entenden. A capacidade ou incapacidade de compartir prácticas, compartir coñecementos, neste sentido tamén é un problema.
Ben, escalando os recursos. "Xenial, imos! E agora queremos máis rápido, máis. Que, non podes? Non é posible entregar o dobre nun ano? E por que?" Tales dores de crecemento probablemente sexan estándar para moitas cousas, moitos enfoques, e podes sentilos.
En canto ao seguimento. Paréceme que os servizos ou as ferramentas de vixilancia industrial xa están aprendendo ou son capaces de traballar tanto con Docker como con Kubernetes nun modo diferente e non estándar. Para que, por exemplo, non acabes con 500 máquinas Java nas que se executa todo isto, é dicir, se agrega. Pero estes produtos aínda carecen de madurez, teñen que pasar por iso. O tema é realmente novo, seguirá desenvolvéndose.
Dimitri:
Si, moi interesante. E isto aplícase a RRHH. Quizais o teu proceso de RRHH e a túa marca de RRHH cambiaron un pouco ao longo destes 3 anos. Comezaches a contratar outras persoas con diferentes competencias. E probablemente haxa pros e contras. Anteriormente, a cadea de bloques e a ciencia de datos eran o bombo e os especialistas neles valían millóns. Agora o custo está caendo, o mercado está a saturarse e hai unha tendencia similar nos microservizos.
Sergey:
Si, absolutamente.
Alexandre:
RRHH fai a pregunta: "Onde está o teu unicornio rosa entre o backend e o frontend?" RRHH non entende o que é un microservizo. Contámoslles o segredo e dixémoslles que o backend facía de todo e que non hai unicornio. Pero RRHH está a cambiar, aprendendo rapidamente e reclutando persoas que teñan coñecementos básicos de TI.
A evolución dos microservizos
Dimitri:
Se observas a arquitectura de destino, os microservizos parecen un monstro. A túa viaxe levou varios anos. Outros teñen un ano, outros tres. Previu todos os problemas, a arquitectura de destino, cambiou algo? Por exemplo, no caso dos microservizos, agora aparecen de novo as pasarelas e as mallas de servizos. Utilizábaas ao principio ou cambiaches a propia arquitectura? Tes tales retos?
Sergey:
Xa reescribimos varios protocolos de comunicación. Ao principio había un protocolo, agora pasamos a outro. Aumentamos a seguridade e a fiabilidade. Comezamos con tecnoloxías empresariais: Oracle, Web Logic. Agora estamos a afastarnos dos produtos tecnolóxicos empresariais en microservizos e pasamos a tecnoloxías de código aberto ou completamente abertas. Abandonamos as bases de datos e pasamos ao que nos funciona máis eficazmente neste modelo. Xa non necesitamos tecnoloxías Oracle.
Comezamos simplemente como un servizo, sen pensar en canto necesitabamos unha caché, que faríamos cando non houbese conexión cun microservizo, pero se precisaban datos, etc. Agora estamos a desenvolver unha plataforma para que se poida describir a arquitectura. non na linguaxe dos servizos, e na linguaxe empresarial, leva a lóxica empresarial ao seguinte nivel cando comezamos a falar con palabras. Agora aprendemos a falar con letras, e o seguinte nivel é cando os servizos se recollerán nun tipo de agregado, cando esta xa é unha palabra, por exemplo, unha tarxeta de produto enteira. Está montado a partir de microservizos, pero é unha API construída sobre isto.
A seguridade é moi importante. En canto comezas a ser accesible e tes un servizo a través do cal podes conseguir moitas cousas interesantes, e moi rapidamente, nunha fracción de segundo, hai o desexo de conseguilo dunha forma non do máis segura. Para fuxir disto, tivemos que cambiar os enfoques das probas e do seguimento. Tivemos que cambiar o equipo, a estrutura de xestión da entrega, CI/CD.
Esta é unha evolución, como cos teléfonos, só que moito máis rápido: primeiro houbo teléfonos con botóns, despois apareceron os teléfonos intelixentes. Reescribiron e redesearon o produto porque o mercado tiña unha necesidade diferente. Así evolucionamos: primeiro, décimo, traballo.
Iterativamente, exponse algo ao ano dende o punto de vista da tecnoloxía, outra cousa dende o punto de vista do atraso e das necesidades. Conectamos unha cousa coa outra. O equipo gasta o 20% en débeda técnica e soporte técnico para o equipo, o 80% na entidade empresarial. E movémonos entendendo por que o facemos, por que estamos a facer estas melloras tecnolóxicas, a que levarán. Así.
Dimitri:
Genial. Que hai en MegaFon?
Alexandre:
O principal reto cando chegamos aos microservizos era non caer no caos. A oficina de arquitectura de MegaFon uniuse de inmediato a nós, incluso se converteu nun iniciador e condutor; agora temos unha arquitectura moi forte. A súa tarefa foi comprender a que modelo obxectivo imos e que tecnoloxías hai que pilotar. Coa arquitectura, realizamos estes pilotos nós mesmos.
A seguinte pregunta foi: "Entón, como explotar todo isto?" E unha máis: "Como garantir a interacción transparente entre os microservizos?" A malla de servizo axudounos a responder á última pregunta. Pilotamos Istio e gustounos os resultados. Agora estamos na fase de implantación en zonas produtivas. Temos unha actitude positiva ante todos os desafíos: o feito de que necesitamos cambiar constantemente a pila, aprender algo novo. Interésanos desenvolver, non explotar solucións antigas.
Dimitri:
Palabras de ouro! Estes desafíos manteñen o equipo e as empresas alerta e crean o futuro. GDPR creou xefes de protección de datos e os desafíos actuais crean xefes de microservizos e de arquitectura. E agrada.
Discutimos moito. O principal é que un bo deseño de microservizos e a propia arquitectura permite evitar moitos erros. Por suposto, o proceso é iterativo e evolutivo, pero é o futuro.
Grazas a todos os participantes, grazas a Sergei e Alexander!
Preguntas do público
Pregunta do público (1):
Sergey, como cambiou a xestión de TI na túa empresa? Entendo que cando hai unha pila grande de varios sistemas, como se xestiona é un proceso bastante claro e lóxico. Como reconstruíches a xestión do compoñente informático despois de que se integrasen un gran número de microservizos en tan pouco tempo?
Sergey:
Coincido co meu compañeiro en que a arquitectura é moi importante como motor de cambio. Comezamos por ter unha división de arquitectura. Os arquitectos son ao mesmo tempo os propietarios da distribución da funcionalidade e dos requisitos de como aparecerá na paisaxe. Por iso tamén actúan como coordinadores destes cambios. Como resultado, houbo cambios específicos nun proceso de entrega específico cando creamos unha plataforma CI/CD.
Pero o estándar, os principios básicos de desenvolvemento, análise de empresas, probas e desenvolvemento non foron cancelados. Só engadimos velocidade. Anteriormente, o ciclo levaba moito, a instalación en ambientes de proba levaba moito máis. Agora as empresas ven o beneficio e preguntan: "Por que non podemos facer o mesmo noutros lugares?"
É como, en boa forma, unha inxección en forma de vacina que demostrou: podes facelo deste xeito, pero podes facelo doutro xeito. Por suposto, hai un problema de persoal, de competencias, de coñecementos, de resistencia.
Pregunta do público (2):
Os críticos da arquitectura de microservizos din que as probas e o desenvolvemento son difíciles. Isto é lóxico cando as cousas se complican. Que retos enfrontou o teu equipo e como os superaches? Pregunta para todos.
Alexandre:
Hai dificultades ao pasar de microservizos a unha plataforma, pero pódense solucionar.
Por exemplo, estamos a facer un produto que consta de 5-7 microservizos. Necesitamos ofrecer probas de integración en toda a pila de microservizos para dar luz verde para pasar á rama mestra. Esta tarefa non era nova para nós: levabamos moito tempo facendo isto en BSS, cando o vendedor nos proporcionou solucións xa enviadas.
E o noso problema só está no equipo pequeno. Precísase un enxeñeiro de control de calidade para un produto condicional. E así, enviamos un produto de 5-7 microservizos, dos cales 2-3 poden ser desenvolvidos por terceiros. Por exemplo, temos un produto en cuxo desenvolvemento participan o provedor do noso sistema de facturación, Mail.ru Group e MegaFon I+D. Debemos cubrir isto con probas antes de envialo á produción. O enxeñeiro de control de calidade leva mes e medio traballando neste produto e o resto do equipo queda sen o seu apoio.
Esta complexidade só é causada pola escala. Entendemos que os microservizos non poden existir nun baleiro; non existe un illamento absoluto. Ao cambiar un servizo, sempre intentamos conservar o contrato da API. Se algo cambia debaixo do capó, o servizo dianteiro permanece. Se os cambios son fatales, prodúcese algún tipo de transformación arquitectónica e pasamos a un metamodelo de datos completamente diferente, que é completamente incompatible; só entón falamos de que aparece a especificación da API do servizo v2. Admitimos a primeira e a segunda versións simultaneamente, e despois de que todos os consumidores cambien á segunda versión, simplemente pechamos a primeira.
Sergey:
Quero engadir. Estou absolutamente de acordo sobre as complicacións: ocorren. O panorama é cada vez máis complexo e os custos xerais aumentan, especialmente para as probas. Como xestionar isto: cambia a probas automatizadas. Si, terás que investir adicionalmente en escribir autotests e probas unitarias. Para que os desenvolvedores non puidesen comprometerse sen pasar a proba, non podían cambiar o código. Para que nin sequera o pulsador funcione sen autotest, proba unitaria.
É importante manter a funcionalidade anterior, e isto é unha sobrecarga adicional. Se reescribe unha tecnoloxía noutro protocolo, entón reescribe ata que pecha todo por completo.
Ás veces non facemos probas de extremo a extremo adrede, porque non queremos parar o desenvolvemento, aínda que tamén temos unha cousa tras outra. A paisaxe é moi grande, complexa, hai moitos sistemas. Ás veces son só esbozos: si, baixas a marxe de seguridade, aparecen máis riscos. Pero ao mesmo tempo liberas a oferta.
Alexandre:
Si, as probas automáticas e as unitarias permítenche crear un servizo de alta calidade. Estamos a favor dun gasoduto que non se pode superar sen probas unitarias e de integración. Moitas veces temos que arrastrar emuladores e sistemas comerciais a zonas de proba e entornos de desenvolvemento, porque non todos os sistemas se poden colocar en zonas de proba. Ademais, non só se mollan: xeramos unha resposta completa do sistema. Esta é unha parte importante do traballo con microservizos, e tamén estamos investindo nel. Sen isto, producirase o caos.
Pregunta do público (3):
Polo que entendo, os microservizos creceron inicialmente a partir dun equipo separado e agora existen neste modelo. Cales son os seus pros e contras?
Só temos unha historia semellante: xurdiu unha especie de fábrica de microservizos. Agora chegamos conceptualmente ao punto de que estendemos este enfoque á produción por fluxos e por sistemas. Noutras palabras, afastámonos do desenvolvemento centralizado de microservizos, modelos de microservizos, e estamos cada vez máis preto dos sistemas.
En consecuencia, o noso funcionamento tamén se dirixe aos sistemas, é dicir, estamos descentralizando este tema. Cal é o teu enfoque e cal é a túa historia obxectivo?
Alexandre:
Quitaches o nome de "fábrica de microservizos" directamente da túa boca; tamén queremos escalar. En primeiro lugar, agora temos un equipo. Queremos ofrecer a todos os equipos de desenvolvemento que MegaFon ten a oportunidade de traballar nun ecosistema común. Non queremos asumir por completo toda a funcionalidade de desenvolvemento que temos agora. A tarefa local é escalar, a tarefa global é levar o desenvolvemento a todos os equipos da capa de microservizos.
Sergey:
Vouvos contar o camiño que tomamos. Realmente comezamos a traballar en equipo, pero agora non estamos sós. Son partidario do seguinte: debe haber un dono do proceso. Alguén precisa comprender, xestionar, controlar e construír o proceso de desenvolvemento de microservizos. Debe posuír recursos e participar na xestión dos recursos.
Estes recursos, que coñecen tecnoloxías, detalles específicos e entenden como construír microservizos, pódense localizar nos equipos de produtos. Temos unha mestura onde a xente da plataforma de microservizos está no equipo de produto que fai a aplicación móbil. Están aí, pero traballan segundo o proceso do departamento de xestión da plataforma de microservizos co seu xestor de desenvolvemento. Dentro desta división hai un equipo separado que se ocupa da tecnoloxía. É dicir, mesturamos un conxunto común de recursos entre nós e dividímolos, dándoos aos equipos.
Ao mesmo tempo, o proceso segue sendo xeral, controlado, procede segundo os principios tecnolóxicos xerais, con probas unitarias e así por diante, todo o que se constrúe encima. Pode haber columnas en forma de recursos recollidos de diferentes departamentos do enfoque do produto.
Alexandre:
Sergey, en realidade es o propietario do proceso, non? Compártese o atraso de tarefas? Quen é o responsable da súa distribución?
Sergey:
Mira: aquí está a mestura de novo. Hai un atraso que se forma en base a melloras tecnolóxicas: esta é unha historia. Hai un atraso, que se formula a partir de proxectos, e hai un atraso de produtos. Pero a secuencia de introdución en cada un dos produtos do servizo ou a creación deste servizo é desenvolvida por un especialista en produtos. Non está na dirección de informática, foi especialmente retirado dela. Pero a miña xente definitivamente traballa segundo o mesmo proceso.
O propietario do atraso en diferentes direccións (o atraso de cambios) será persoas diferentes. A conexión dos servizos tecnolóxicos, o seu principio organizador - todo isto será en TI. Tamén teño a plataforma e os recursos. Na parte superior está o que se refire ao atraso e os cambios funcionais, e a arquitectura neste sentido.
Digamos que unha empresa di: "Queremos esta función, queremos crear un produto novo - refacer un préstamo". Respondemos: "Si, imos refacelo". Os arquitectos din: "Pensemos: onde no préstamo escribiremos microservizos e como o faremos?" Despois divímolo en proxectos, produtos ou unha pila de tecnoloxía, poñémolo en equipos e implementámolo. Creaches un produto internamente e decidiches usar microservizos neste produto? Dicimos: "Agora os sistemas legados que tiñamos, ou os sistemas de primeira liña, deben cambiar a estes microservizos". Os arquitectos din: "Entón: no atraso tecnolóxico dentro dos produtos de primeira liña - a transición aos microservizos. Vaia". E os especialistas en produtos ou os empresarios entenden canta capacidade se asigna, cando se fará e por que.
O final da discusión, pero non todo
Organizouse a conferencia mailto:CLOUD .
Tamén facemos outros eventos, por exemplo. Encontro @Kubernetes, onde sempre buscamos excelentes relatores:
- Siga @Kubernetes e outras novas de @Meetup na nosa canle de Telegram
- Interesado en falar nun dos @Meetups? Deixe unha solicitude para
Fonte: www.habr.com