El 25 d'abril, a Mail.ru Group vam fer una conferència sobre els núvols i al voltant - . Alguns aspectes destacats:
- El principal — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center i Yandex.Cloud van parlar sobre les especificitats del nostre mercat del núvol i els seus serveis;
- Els companys de Bitrix24 van explicar com ho van fer ;
- Leroy Merlin, Otkritie, Burger King i Schneider Electric van oferir interessants — quines tasques estableix el seu negoci per a TI i quines tecnologies, incloses les del núvol, veuen com les més prometedores.
Podeu veure tots els vídeos de la conferència mailto:CLOUD , i aquí podeu llegir com va anar la discussió sobre els microserveis. Alexander Deulin, cap del centre d'investigació i desenvolupament de sistemes empresarials MegaFon, i Sergey Sergeev, director de tecnologia de la informació del grup M.Video-Eldorado, van compartir els seus casos d'èxit de desfer-se dels monòlits. També vam parlar de qüestions relacionades amb l'estratègia informàtica, els processos i fins i tot els recursos humans.
Panelistes
- Serguei Sergeev, CIO del grup "M.Video-Eldorado";
- Alexandre Deulin, responsable del centre de recerca i desenvolupament de sistemes empresarials MegaFon;
- Moderador - Dmitri Lazarenko, Cap de direcció PaaS Mail.ru Solucions al núvol.
Després del discurs d'Alexander Deulin Sergey Sergeev, de M.Video-Eldorado, i el moderador de discussió Dmitry Lazarenko, Mail.ru Cloud Solutions, s'uneixen per a la discussió.
A continuació us hem preparat una transcripció de la discussió, però també podeu veure el vídeo:
La transició als microserveis és una resposta a les necessitats del mercat
Dmitriy:
Heu tingut alguna experiència exitosa amb la migració a microserveis? I en general: on veus el major benefici empresarial de l'ús de microserveis o de passar dels monòlits als microserveis?
Sergey:
Ja hem fet algun camí en la transició als microserveis i fa més de tres anys que utilitzem aquest enfocament. La primera necessitat que va justificar la necessitat de microserveis va ser la integració sense fi de diversos productes front-end amb el back office. I cada vegada ens vam veure obligats a fer una integració i desenvolupament addicionals, implementant les nostres pròpies regles per al funcionament d'aquest o aquell servei.
En algun moment, ens vam adonar que necessitàvem accelerar el funcionament dels nostres sistemes i la sortida de la funcionalitat. En aquell moment, conceptes com els microserveis i un enfocament de microserveis ja existien al mercat, i vam decidir provar-ho. Això va començar el 2016. Després es va posar la plataforma i els primers 10 serveis van ser implementats per un equip independent.
Un dels primers serveis, el més carregat, va ser el servei de càlcul de preus. Cada vegada que arribeu a qualsevol canal, al grup d'empreses M.Video-Eldorado, ja sigui una pàgina web o una botiga minorista, seleccioneu-hi un producte, consulteu el preu a la web o a la "Cistella", el cost és automàticament calculat per un servei. Per què és necessari: abans d'això, cada sistema tenia els seus propis principis per treballar amb promocions, amb descomptes, etc. El nostre back office gestiona els preus; la funcionalitat de descompte s'implementa en un altre sistema. Calia centralitzar-ho i crear un servei únic i separable en forma de procés de negoci que ens permetés implementar-ho. Pràcticament així és com vam començar.
El valor dels primers resultats va ser molt gran. En primer lloc, hem pogut crear entitats separables que ens permeten treballar per separat i de manera agregada. En segon lloc, hem reduït el cost de propietat pel que fa a la integració amb més sistemes.
Durant els últims tres anys, hem afegit tres sistemes de primera línia. Era difícil mantenir-los amb la mateixa quantitat de recursos que es podia permetre l'empresa. Per això, va sorgir la tasca de buscar nous punts de venda, responent al mercat en termes de rapidesa, en termes de costos interns i d'eficiència.
Com mesurar l'èxit de la migració a microserveis
Dmitriy:
Com es determina l'èxit en la migració als microserveis? Quin era l'"abans" a cada empresa? Quina mètrica vau utilitzar per determinar l'èxit de la transició i qui la va determinar realment?
Sergey:
En primer lloc, va néixer dins de les TI com a activador: "desbloquejar" noves capacitats. Teníem la necessitat de fer-ho tot més ràpidament per relativament els mateixos diners, responent als reptes del mercat. Ara l'èxit s'expressa en el nombre de serveis reutilitzats per diferents sistemes, unificació de processos entre ells. Ara sí, però en aquell moment era una oportunitat per crear una plataforma i confirmar la hipòtesi que podem fer-ho, donarà efecte i calcularà el cas de negoci.
Alexandre:
L'èxit és més aviat un sentiment intern. Les empreses sempre volen més, i la profunditat del nostre backlog és una prova d'èxit. A mi em sembla així.
Sergey:
Sí estic d'acord. En tres anys, ja tenim més de dos-cents serveis i endarreri. La necessitat de recursos dins de l'equip només està creixent: un 30% anual. Això passa perquè la gent sentia: és més ràpid, és diferent, hi ha diferents tecnologies, tot això s'està desenvolupant.
Els microserveis vindran, però el nucli es mantindrà
Dmitriy:
És com un procés interminable on inverteixes en desenvolupament. La transició als microserveis per a empreses ja s'ha acabat o no?
Sergey:
És molt fàcil de respondre. Què en penseu: substituir els telèfons és un procés sense fi? Nosaltres mateixos comprem telèfons cada any. I aquí està: sempre que calgui rapidesa, per adaptar-se al mercat, caldran alguns canvis. Això no vol dir que abandonem les coses estàndard.
Però no podem cobrir i refer tot alhora. Tenim serveis d'integració estàndards heretats que existien abans: autobusos empresarials, etc. Però hi ha un endarreriment, i també hi ha una necessitat. El nombre d'aplicacions mòbils i la seva funcionalitat està creixent. Al mateix temps, ningú diu que se't donarà un 30% més de diners. És a dir, sempre hi ha necessitats d'una banda, i una recerca de l'eficiència de l'altra.
Dmitriy:
La vida està en bon estat. (riu)
Alexandre:
En general, sí. No tenim enfocaments revolucionaris per eliminar la part central del paisatge. S'està treballant sistemàticament per descompondre els sistemes perquè siguin més coherents amb l'arquitectura de microserveis, per reduir la influència dels sistemes entre si.
Però pensem mantenir la part central, ja que en el panorama de l'operador sempre hi haurà algunes plataformes que comprem. De nou, necessitem un equilibri saludable: no hem de precipitar-nos a tallar el nucli. Col·loquem els sistemes un al costat de l'altre, i ara resulta que ja estem al damunt de moltes parts bàsiques. A més, desenvolupant la funcionalitat, creem les representacions necessàries per a tots els canals que funcionen amb els nostres serveis de comunicació.
Com vendre microserveis a empreses
Dmitriy:
També m'interessa, per a aquells que no s'han canviat, però tenen previst fer-ho: com de fàcil va ser vendre aquesta idea a les empreses i va ser una aventura, un projecte d'inversió? O va ser una estratègia conscient: ara anem als microserveis i ja està, res ens aturarà. Com et va anar?
Sergey:
No veníem un enfocament, sinó un benefici empresarial. Hi havia un problema als negocis i vam intentar resoldre'l. En aquell moment, es va expressar en el fet que diferents canals utilitzaven principis diferents per calcular els preus: per separat per a promocions, per a promocions, etc. Va ser difícil de mantenir, es van produir errors i vam escoltar les queixes dels clients. És a dir, veníem una solució a un problema, però vam venir amb el fet que necessitàvem diners per crear una plataforma. I van mostrar un cas de negoci amb l'exemple de la primera etapa d'inversió: com la continuarem recuperant i què ens permetrà fer.
Dmitriy:
Has gravat d'alguna manera el temps de la primera etapa?
Sergey:
Si, es clar. Hem destinat 6 mesos per crear el nucli com a plataforma i provar el pilot. Durant aquest temps, vam intentar crear una plataforma sobre la qual patinar el pilot. Aleshores es va confirmar la hipòtesi, i com que funciona, vol dir que podem continuar. Van començar a replicar i enfortir l'equip: el van traslladar a una divisió separada que fa exactament això.
A continuació, ve el treball sistemàtic basat en les necessitats empresarials, les oportunitats, la disponibilitat de recursos i tot el que està en marxa actualment.
Dmitriy:
D'ACORD. Alexandre, què dius?
Alexandre:
Els nostres microserveis neixen de l'"escuma del mar" -per l'estalvi de recursos, per algunes restes en forma de capacitat del servidor i la redistribució de forces dins de l'equip. Inicialment, no veníem aquest projecte a les empreses. Aquest va ser un projecte on tots dos hem investigat i desenvolupat en conseqüència. Vam començar a principis del 2018 i simplement vam desenvolupar aquesta direcció amb entusiasme. Les vendes acaben de començar i estem en procés.
Dmitriy:
Succeeix que una empresa et permet fer coses com Google, un dia gratuït a la setmana? Tens aquesta direcció?
Alexandre:
Paral·lelament a la investigació, també tractem problemes empresarials, de manera que tots els nostres microserveis són solucions als problemes empresarials. Només al principi vam construir microserveis que cobrien una petita part de la base de subscriptors, i ara estem presents en gairebé tots els productes emblemàtics.
I l'impacte material ja és evident: ja ens podem comptar, es pot estimar la velocitat dels llançaments de productes i la pèrdua d'ingressos si haguéssim seguit l'antic camí. Això és el que estem construint el cas.
Microserveis: bombo o necessitat?
Dmitriy:
Els números són números. I els ingressos o els diners estalviats són molt importants. Què passa si mires a l'altre costat? Sembla que els microserveis són una tendència, un bombo i moltes empreses n'abusen? Quina claritat diferencies entre el que fas i el que no tradueixes a microserveis? Si el llegat ara, encara tindràs el llegat d'aquí a 5 anys? Quina serà l'edat dels sistemes d'informació que funcionen a M.Video-Eldorado i MegaFon d'aquí a 5 anys? Hi haurà sistemes d'informació de deu, quinze anys o serà una nova generació? Com veus això?
Sergey:
Em sembla que costa pensar molt lluny. Si mirem enrere, qui s'imaginava que el mercat tecnològic es desenvoluparia d'aquesta manera, inclòs l'aprenentatge automàtic i la identificació d'usuaris per cara? Però si ens fixem en els propers anys, em sembla que els sistemes bàsics, els sistemes empresarials de classe ERP a les empreses, han estat treballant durant força temps.
Les nostres empreses tenen col·lectivament 25 anys, amb un ERP clàssic molt profund en el panorama dels sistemes. Està clar que traiem algunes peces d'allà i intentem agregar-les en microserveis, però el nucli es mantindrà. Ara em costa imaginar que substituirem tots els sistemes bàsics allà i passarem ràpidament a l'altre costat brillant dels nous sistemes.
Soc partidari del fet que tot allò que està més a prop del client i del consumidor és on hi ha el major benefici i valor empresarial, on l'adaptabilitat i l'enfocament en la velocitat, en el canvi, en "provar, cancel·lar, reutilitzar, fer alguna cosa diferent". necessari “—allà és on canviarà el paisatge. I els productes en caixa no hi caben gaire bé. Almenys no ho veiem. Allà es requereixen les solucions més senzilles i senzilles.
Veiem aquest desenvolupament:
- sistemes d'informació bàsics (majoritàriament back office);
- les capes mitjanes en forma de microserveis connecten el nucli, s'agreguen, creen una memòria cau, etc.
- els sistemes de primera línia estan dirigits al consumidor;
- una capa d'integració que generalment s'integra en mercats, altres sistemes i ecosistemes. Aquesta capa és tan lleugera com sigui possible, senzilla i conté un mínim de lògica empresarial.
Però, al mateix temps, sóc partidari de continuar utilitzant els principis antics si s'utilitzen adequadament.
Suposem que teniu un sistema empresarial clàssic. Es troba al paisatge d'un venedor i consta de dos mòduls que funcionen entre si. També hi ha una interfície d'integració estàndard. Per què refer-ho i portar-hi un microservei?
Però quan hi ha 5 mòduls a l'oficina de fons, dels quals es recullen peces d'informació en un procés de negoci, que després són utilitzats per 8-10 sistemes de primera línia, el benefici es nota immediatament. Agafes de cinc sistemes de back-office i crees un servei, un aïllat, centrat en el procés de negoci. Feu que el servei sigui tecnològicament avançat, de manera que emmagatzemi informació a la memòria cau i sigui tolerant a errors, i també funcioni amb documents o entitats comercials. I ho integres segons un principi únic amb tots els productes de primera línia. Van cancel·lar el producte de primera línia; simplement van desactivar la integració. Demà haureu d'escriure una aplicació mòbil o fer un petit lloc web i posar només una part a la funcionalitat: tot és senzill: l'heu muntat com un constructor. Veig més desenvolupament en aquesta direcció, almenys al nostre país.
Alexandre:
Sergey va descriure completament el nostre enfocament, gràcies. Només diré on definitivament no anirem: a la part central, al tema de la facturació en línia. És a dir, la qualificació i la càrrega seguiran sent, de fet, un "gran" trillador que esborrarà els diners de manera fiable. I aquest sistema continuarà sent certificat per les nostres autoritats reguladores. Tot el que mira cap als clients, és clar, són microserveis.
Dmitriy:
Aquí la certificació és una història. Probablement més suport. Si gastes poc en suport o el sistema no requereix suport i modificació, és millor no tocar-lo. Un compromís raonable.
Com desenvolupar microserveis fiables
Dmitriy:
Bé. Però encara estic interessat. Ara estàs explicant una història d'èxit: tot anava bé, vam canviar als microserveis, vam defensar la idea al negoci i tot va sortir. Però he sentit altres històries.
Fa un parell d'anys, una empresa suïssa que havia invertit dos anys en el desenvolupament d'una nova plataforma de microserveis per als bancs finalment va tancar el projecte. Completament col·lapsat. Es van gastar molts milions de francs suïssos i, al final, l'equip es va dispersar, no va funcionar.
Has tingut històries semblants? Hi ha hagut o hi ha dificultats? Per exemple, mantenir els microserveis i el seguiment també és un maldecap en les activitats operatives de l'empresa. Després de tot, el nombre de components augmenta desenes de vegades. Com ho veus, hi ha hagut exemples d'inversions sense èxit aquí? I què pots aconsellar a la gent perquè no es trobin amb aquests problemes?
Alexandre:
Els exemples sense èxit van incloure empreses que canvien les prioritats i cancel·len projectes. Quan es trobava en una bona fase de preparació (de fet, l'MVP està a punt), el negoci va dir: "Tenim noves prioritats, passem a un altre projecte i estem tancant aquest".
No hem tingut cap fallada global amb els microserveis. Dormim tranquils, tenim un torn de servei les 24 hores del dia, els 7 dies de la setmana, que dóna servei a tot el BSS [sistema de suport empresarial].
I una cosa més: lloguem microserveis segons les normes que s'apliquen als productes en caixa. La clau de l'èxit és que cal, en primer lloc, reunir un equip que prepari completament el microservei per a la producció. El desenvolupament en si és, condicionalment, del 40%. La resta són analítiques, metodologia DevSecOps, les integracions adequades i l'arquitectura adequada. Prestem especial atenció als principis de creació d'aplicacions segures. Els representants de seguretat de la informació participen en cada projecte tant en l'etapa de planificació de l'arquitectura com durant el procés d'implementació. També gestionen sistemes per analitzar codi per detectar vulnerabilitats.
Suposem que despleguem els nostres serveis sense estat: els tenim a Kubernetes. Això permet que tothom dormi tranquil a causa de l'escala automàtica i l'augment automàtic dels serveis, i el torn de servei recull incidents.
En tota l'existència dels nostres microserveis només hi ha hagut una o dues incidències que han arribat a la nostra línia. Ara no hi ha problemes amb el funcionament. Per descomptat, no tenim 200, sinó uns 50 microserveis, però s'utilitzen en productes emblemàtics. Si fracassaven, seríem els primers a saber-ho.
Microserveis i RRHH
Sergey:
Estic d'acord amb el meu company sobre el trasllat al suport - que el treball s'ha d'organitzar correctament. Però us explicaré els problemes que, és clar, existeixen.
En primer lloc, la tecnologia és nova. Aquest és un bombo en bona manera, i trobar un especialista que entengui i pugui crear això és un gran repte. La competència pels recursos és boja, així que els experts valen el seu pes en or.
En segon lloc, amb la creació de determinats paisatges i un nombre creixent de serveis, s'ha de resoldre constantment el problema de la reutilització. Com els agrada fer als desenvolupadors: "Escrivim ara moltes coses interessants aquí..." Per això, el sistema creix i perd la seva eficàcia en termes de diners, cost de propietat, etc. És a dir, cal incloure la reutilització en l'arquitectura del sistema, incloure-la en el full de ruta per introduir serveis i transferir el llegat a una nova arquitectura.
Un altre problema, encara que això sigui bo a la seva manera, és la competència interna. "Oh, han aparegut nous nois de moda aquí, parlen un nou idioma". La gent, és clar, és diferent. Hi ha qui està acostumat a escriure en Java, i qui escriu i utilitza Docker i Kubernetes. Són persones completament diferents, parlen de manera diferent, utilitzen termes diferents i de vegades no s'entenen. La capacitat o incapacitat de compartir pràctiques, compartir coneixements, en aquest sentit també és un problema.
Bé, escalant els recursos. “Genial, anem! I ara volem més ràpid, més. Què, no pots? No és possible lliurar el doble en un any? I per què?" Aquests dolors de creixement probablement són estàndard per a moltes coses, molts enfocaments, i els podeu sentir.
Pel que fa al seguiment. Em sembla que els serveis o les eines de monitorització industrial ja estan aprenent o poden treballar tant amb Docker com amb Kubernetes d'una manera diferent i no estàndard. De manera que, per exemple, no acabeu amb 500 màquines Java en què s'executa tot això, és a dir, s'agrega. Però aquests productes encara no tenen maduresa, han de passar per això. El tema és realment nou, seguirà desenvolupant-se.
Dmitriy:
Sí, molt interessant. I això s'aplica a RRHH. Potser el vostre procés de recursos humans i la vostra marca de recursos humans han canviat una mica durant aquests 3 anys. Vau començar a reclutar altres persones amb diferents competències. I probablement hi hagi pros i contres. Anteriorment, la cadena de blocs i la ciència de dades eren el bombo, i els especialistes en ells valien milions. Ara el cost està baixant, el mercat s'està saturant i hi ha una tendència similar als microserveis.
Sergey:
Sí, absolutament.
Alexandre:
HR fa la pregunta: "On és el teu unicorn rosa entre el backend i el frontend?" RRHH no entén què és un microservei. Els vam explicar el secret i els vam dir que el backend ho feia tot i que no hi ha unicorn. Però els recursos humans estan canviant, aprenent ràpidament i reclutant persones amb coneixements bàsics de TI.
L'evolució dels microserveis
Dmitriy:
Si observeu l'arquitectura objectiu, els microserveis semblen un monstre. El teu viatge va durar diversos anys. Altres tenen un any, altres tres anys. Vau preveure tots els problemes, l'arquitectura objectiu, va canviar alguna cosa? Per exemple, en el cas dels microserveis, ara tornen a aparèixer passarel·les i malles de servei. Els vas utilitzar al principi o vas canviar l'arquitectura? Tens aquests reptes?
Sergey:
Ja hem reescrit diversos protocols de comunicació. Al principi hi havia un protocol, ara hem canviat a un altre. Augmentem la seguretat i la fiabilitat. Vam començar amb tecnologies empresarials: Oracle, Web Logic. Ara ens allunyem dels productes empresarials tecnològics en microserveis i passem a tecnologies de codi obert o completament obertes. Abandonem les bases de dades i passem a allò que ens funciona més eficaçment en aquest model. Ja no necessitem les tecnologies Oracle.
Vam començar simplement com un servei, sense pensar en quant necessitàvem una memòria cau, què faríem quan no hi hagués connexió amb un microservei, però calien dades, etc. Ara estem desenvolupant una plataforma perquè es pugui descriure l'arquitectura. no en el llenguatge dels serveis, i en el llenguatge empresarial, portar la lògica empresarial al següent nivell quan comencem a parlar amb paraules. Ara hem après a parlar amb lletres, i el següent nivell és quan els serveis es recolliran en algun tipus d'agregat, quan això ja és una paraula, per exemple, una targeta de producte sencera. Està muntat a partir de microserveis, però és una API construïda a sobre d'això.
La seguretat és molt important. Tan bon punt comences a ser accessible i tens un servei a través del qual pots aconseguir un munt de coses interessants, i molt ràpidament, en una fracció de segon, hi ha la voluntat d'aconseguir-ho d'una manera no la més segura. Per allunyar-nos d'això, vam haver de canviar els enfocaments de les proves i el seguiment. Vam haver de canviar l'equip, l'estructura de gestió de lliurament, CI/CD.
Aquesta és una evolució, com passa amb els telèfons, només que molt més ràpid: primer van aparèixer els telèfons amb botons, després van aparèixer els telèfons intel·ligents. Van reescriure i redissenyar el producte perquè el mercat tenia una necessitat diferent. Així evolucionem: primer, desè, treball.
De manera iterativa, s'estableix alguna cosa per any des del punt de vista de la tecnologia, una altra cosa des del punt de vista de l'endarreriment i les necessitats. Connectem una cosa amb una altra. L'equip gasta el 20% en deute tècnic i suport tècnic per a l'equip, el 80% en l'entitat empresarial. I ens movem amb la comprensió de per què ho fem, per què estem fent aquestes millores tecnològiques, a què comportaran. Així.
Dmitriy:
Guai. Què hi ha a MegaFon?
Alexandre:
El principal repte quan vam arribar als microserveis era no caure en el caos. L'oficina d'arquitectura de MegaFon es va unir immediatament a nosaltres, fins i tot es va convertir en un iniciador i conductor; ara tenim una arquitectura molt forta. La seva tasca era entendre a quin model objectiu anem i quines tecnologies s'han de pilotar. Amb l'arquitectura, hem realitzat aquests pilots nosaltres mateixos.
La següent pregunta va ser: "Llavors, com explotar tot això?" I un més: "Com garantir una interacció transparent entre microserveis?" La malla de servei ens va ajudar a respondre l'última pregunta. Hem pilotat Istio i ens han agradat els resultats. Ara estem en l'etapa de desplegament a zones productives. Tenim una actitud positiva davant tots els reptes: el fet que hem de canviar constantment la pila, aprendre alguna cosa nova. Ens interessa desenvolupar, no explotar solucions antigues.
Dmitriy:
Paraules d'or! Aquests reptes mantenen l'equip i les empreses alerta i creen el futur. El GDPR va crear responsables de protecció de dades en cap i els reptes actuals creen els responsables de microserveis i d'arquitectura. I agrada.
Vam discutir molt. El més important és que un bon disseny dels microserveis i la pròpia arquitectura permet evitar molts errors. Per descomptat, el procés és iteratiu i evolutiu, però és el futur.
Gràcies a tots els participants, gràcies a Sergei i Alexander!
Preguntes de l'audiència
Pregunta de l'audiència (1):
Sergey, com ha canviat la gestió informàtica a la teva empresa? Entenc que quan hi ha una gran pila de diversos sistemes, com es gestiona és un procés bastant clar i lògic. Com vau reconstruir la gestió del component informàtic després d'haver integrat un nombre molt gran de microserveis en tan poc temps?
Sergey:
Estic d'acord amb el meu company que l'arquitectura és molt important com a motor de canvi. Vam començar tenint una divisió d'arquitectura. Els arquitectes són alhora els propietaris de la distribució de la funcionalitat i dels requisits de com apareixerà en el paisatge. Així que també actuen com a coordinadors d'aquests canvis. Com a resultat, hi va haver canvis específics en un procés de lliurament específic quan vam crear una plataforma CI/CD.
Però els principis bàsics estàndard de desenvolupament, anàlisi de negocis, proves i desenvolupament no s'han cancel·lat. Només hem afegit velocitat. Anteriorment, el cicle necessitava molt, la instal·lació en entorns de prova necessitava molt més. Ara les empreses veuen el benefici i diuen: "Per què no podem fer el mateix en altres llocs?"
És com, en bona manera, una injecció en forma de vacuna que demostrava: ho pots fer d'aquesta manera, però ho pots fer d'una altra manera. Per descomptat, hi ha un problema de personal, de competències, de coneixements, de resistència.
Pregunta de l'audiència (2):
Els crítics de l'arquitectura de microserveis diuen que les proves i el desenvolupament són difícils. Això és lògic quan les coses es compliquen. Quins reptes es va enfrontar al teu equip i com els vas superar? Pregunta per a tothom.
Alexandre:
Hi ha dificultats per passar dels microserveis a una plataforma, però es poden solucionar.
Per exemple, estem fent un producte que consta de 5-7 microserveis. Hem de proporcionar proves d'integració a tota la pila de microserveis per donar llum verda per passar a la branca mestra. Aquesta tasca no era nova per a nosaltres: ja feia temps que feia això a BSS, quan el venedor ens va subministrar solucions ja enviades.
I el nostre problema és només en l'equip petit. Es necessita un enginyer de control de qualitat per a un producte condicional. Així, enviem un producte de 5-7 microserveis, dels quals 2-3 poden ser desenvolupats per tercers. Per exemple, tenim un producte en el desenvolupament del qual participen el nostre proveïdor de sistemes de facturació, Mail.ru Group i MegaFon R+D. Hem de cobrir-ho amb proves abans d'enviar-lo a producció. L'enginyer de control de qualitat fa un mes i mig que treballa en aquest producte i la resta de l'equip es queda sense el seu suport.
Aquesta complexitat només és causada per l'escala. Entenem que els microserveis no poden existir en el buit; no existeix l'aïllament absolut. Quan canviem un servei, sempre intentem conservar el contracte de l'API. Si alguna cosa canvia sota el capó, el servei davanter es manté. Si els canvis són fatals, es produeix algun tipus de transformació arquitectònica i passem a un metamodel de dades completament diferent, que és completament incompatible; només llavors parlem de l'aparició de l'especificació de l'API del servei v2. Admetem la primera i la segona versió simultàniament i, després que tots els consumidors canviïn a la segona, simplement tanquem la primera.
Sergey:
Vull afegir. Estic absolutament d'acord amb les complicacions: passen. El panorama és cada cop més complex i els costos generals augmenten, especialment per a les proves. Com fer-ho: canvieu a proves automatitzades. Sí, haureu d'invertir addicionalment en escriure autotests i test unitaris. Perquè els desenvolupadors no poguessin comprometre's sense passar la prova, no podien canviar el codi. Perquè fins i tot el polsador no funcioni sense autotest, prova d'unitat.
És important mantenir la funcionalitat anterior, i això és una sobrecàrrega addicional. Si reescriu una tecnologia a un altre protocol, la reescriu fins que ho tanqueu tot completament.
De vegades no fem proves d'extrem a extrem a propòsit, perquè no volem aturar el desenvolupament, encara que també tenim una cosa rere l'altra. El paisatge és molt gran, complex, hi ha molts sistemes. De vegades només són talons: sí, baixeu el marge de seguretat, apareixen més riscos. Però al mateix temps alliberes el subministrament.
Alexandre:
Sí, les proves automàtiques i les proves unitàries us permeten crear un servei d'alta qualitat. Estem a favor d'un pipeline que no es pot superar sense proves d'unitat i integració. Sovint hem d'arrossegar emuladors i sistemes comercials a zones de prova i entorns de desenvolupament, perquè no tots els sistemes es poden col·locar a zones de prova. A més, no només es mullen, sinó que generem una resposta completa del sistema. Aquesta és una part important del treball amb microserveis, i també estem invertint-hi. Sense això, el caos es produirà.
Pregunta de l'audiència (3):
Pel que tinc entès, els microserveis van créixer inicialment a partir d'un equip separat i ara existeixen en aquest model. Quins són els seus pros i contres?
Només tenim una història semblant: va sorgir una mena de fàbrica de microserveis. Ara, conceptualment, hem arribat al punt en què estem estenent aquest enfocament de la producció a través de fluxos i sistemes. En altres paraules, ens allunyem del desenvolupament centralitzat de microserveis, models de microserveis, i ens apropem als sistemes.
En conseqüència, el nostre funcionament també va als sistemes, és a dir, estem descentralitzant aquest tema. Quin és el teu enfocament i quina és la teva història objectiu?
Alexandre:
T'has deixat el nom de "fàbrica de microserveis" de la boca; també volem escalar. En primer lloc, realment tenim un equip. Volem oferir a tots els equips de desenvolupament que té MegaFon l'oportunitat de treballar en un ecosistema comú. No volem assumir completament totes les funcionalitats de desenvolupament que tenim ara. La tasca local és escalar, la tasca global és liderar el desenvolupament a tots els equips de la capa de microservei.
Sergey:
Us explicaré el camí que hem fet. Realment vam començar a treballar com un sol equip, però ara no estem sols. Sóc defensor del següent: hi ha d'haver un propietari del procés. Algú ha d'entendre, gestionar, controlar i crear el procés de desenvolupament de microserveis. Ha de posseir recursos i participar en la gestió dels recursos.
Aquests recursos, que coneixen les tecnologies, les especificitats i entenen com crear microserveis, es poden localitzar en equips de producte. Tenim una combinació on les persones de la plataforma de microserveis formen part de l'equip de producte que fa l'aplicació mòbil. Hi són, però funcionen segons el procés del departament de gestió de la plataforma de microserveis amb el seu responsable de desenvolupament. Dins d'aquesta divisió hi ha un equip separat que s'ocupa de tecnologia. És a dir, barregem un conjunt de recursos comú entre nosaltres i els dividim, donant-los als equips.
Al mateix temps, el procés segueix sent general, controlat, es desenvolupa segons principis tecnològics generals, amb proves unitàries, etc., tot el que es construeix a sobre. Pot haver-hi columnes en forma de recursos recollits de diferents departaments de l'enfocament del producte.
Alexandre:
Sergey, en realitat ets el propietari del procés, oi? Es comparteix l'endarreriment de tasques? Qui és el responsable de la seva distribució?
Sergey:
Mira: aquí està la barreja de nou. Hi ha un endarreriment que es forma a partir de millores tecnològiques: aquesta és una història. Hi ha un endarreriment, que es formula a partir dels projectes, i hi ha un endarreriment dels productes. Però la seqüència d'introducció a cadascun dels productes de servei o la creació d'aquest servei la desenvolupa un especialista en productes. No està a la direcció d'informàtica, se'n va treure especialment. Però la meva gent definitivament treballa segons el mateix procés.
El propietari de l'endarreriment en diferents direccions (l'endarreriment dels canvis) serà persones diferents. La connexió dels serveis tecnològics, el seu principi organitzatiu, tot això serà a les TI. També sóc propietari de la plataforma i dels recursos. A la part superior hi ha el que fa referència a l'endarreriment i als canvis funcionals, i l'arquitectura en aquest sentit.
Suposem que una empresa diu: "Volem aquesta funció, volem crear un producte nou - refer un préstec". Contestem: "Sí, ho tornarem a fer". Els arquitectes diuen: "Pensem: on del préstec escriurem els microserveis i com ho farem?" Després ho desglossem en projectes, productes o una pila tecnològica, ho posem en equip i ho implementem. Heu creat un producte internament i heu decidit utilitzar microserveis en aquest producte? Diem: "Ara els sistemes heretats que teníem, o els sistemes de primera línia, han de canviar a aquests microserveis". Els arquitectes diuen: "Així doncs: en l'endarreriment tecnològic dins dels productes de primera línia: la transició als microserveis. Aneu". I els especialistes en productes o els propietaris d'empreses entenen quanta capacitat s'assigna, quan es farà i per què.
El final de la discussió, però no tot
Es va organitzar la conferència mailto:CLOUD .
També fem altres esdeveniments, p. Trobada @Kubernetes, on sempre busquem grans ponents:
- Segueix @Kubernetes i altres notícies de @Meetup al nostre canal de Telegram
- T'interessa parlar en una de les @Meetups? Deixeu una sol·licitud per
Font: www.habr.com