{"id":53442,"date":"2019-12-02T00:00:00","date_gmt":"2019-12-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/legacy-servisy-v-vashej-infrastrukture"},"modified":"2020-02-18T14:01:20","modified_gmt":"2020-02-18T11:01:20","slug":"legacy-servisy-v-vashej-infrastrukture","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/legacy-servisy-v-vashej-infrastrukture","title":{"rendered":"Legacy-diensten in uw infrastructuur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo! Mijn naam is Pasha Chernyak, ik ben de hoofduitvoerder bij QIWI, en vandaag wil ik het hebben over het onvermijdelijke. Over Legacy.<\/p>\n

Laten we beginnen met de vraag: wat is een Legacy-service? Is een Legacy-service een service waar de ontwikkelaar al een week\/maand\/jaar niet naar heeft gekeken? Of is het een service die is geschreven door een minder ervaren programmeur, bijvoorbeeld door jou, maar dan een jaar geleden? Maar nu ben je beter en ervaren. Of is een Legacy-service een service die je hebt besloten nooit meer te committen en waar je stilletjes een vervanging voor aan het voorbereiden bent? Hoe dan ook, zo'n service onbeheerd en niet bij te werken laten, is een tijdbom die later kan ontploffen.<\/p>\n

\"Legacy-diensten<\/a><\/noindex><\/p>\n

Voordat we ingaan op hoe we bij QIWI omgaan met onze Legacy-services, zal ik vertellen hoe we orde op zaken hebben gesteld met de services in de Portemonnee. Ik ben al twee jaar verantwoordelijk voor de werking ervan. Als er een probleem is, bellen ze altijd in de eerste plaats mij. Ik heb meestal niet het lef om om 11 uur 's avonds iemand anders te bellen, dus moest ik altijd zelf aan de slag met alle services in ons domein. <\/p>\n

Maar ik, net als elke andere persoon, hou ervan om 's nachts te slapen, dus probeerde ik uit te zoeken wat er misging: \"Jongens, waarom bellen jullie mij?\" Waarop ik een vrij beknopt antwoord kreeg: \"Wie anders?\" Omdat ik de services repareer, maar de mensen weten simpelweg niet wie ze anders moeten bellen.<\/p>\n

Daarom hebben we tijdens een van de retro-sessies van het backend-team van de Portemonnee besloten dat we een tabel moesten opstellen met daarop een lijst van onze services, microservices en monolieten van de portemonnee, en de verantwoordelijken daarvoor. Tabellen zijn over het algemeen nuttig, binnen redelijke grenzen.
\n<\/a><\/noindex>
\nNaast de informatie over wie waarvoor verantwoordelijk is, stonden er antwoorden op vragen: wie de eigenaar van de service is, wie verantwoordelijk is voor de ontwikkeling, de architectuur en de levenscyclus. Mensen die verantwoordelijk zijn voor deze service, zijn de mensen die deze in geval van problemen kunnen repareren. De eigenaar van de service heeft het recht om +2 in de commits achter te laten; de verantwoordelijken moeten ook verplicht aanwezig zijn bij de review voordat deze service een nieuwe commit accepteert.<\/p>\n

De tijd verstreek en nieuwe praktijken werden toegepast, zoals migratie naar Kubernetes, verschillende checkstyle, spotbugs, ktlint, het hebben van logs in Kibana, autodiscovery van services in plaats van direct adressen op te geven en andere nuttige zaken. En overal stelde onze tabel ons in staat om de actualiteit van onze services te waarborgen. Voor ons is dit een soort checklist die aangeeft dat deze service dit kan doen, maar dat nog niet. Maar we gingen verder, ons realiserend dat we informatie misten over onze services, waarvoor we toezicht houden, waar de bronbestanden van de service zich bevinden, waar de taken voor de build draaien in TeamCity, hoe ze worden gedeployed, waar de bronbestanden van end2end tests zijn opgeslagen, foto's van de architectuur, over genomen beslissingen. Idealiter wilden we dat al deze informatie ergens beschikbaar was en binnen handbereik wanneer nodig. Daarom werd onze tabel het vertrekpunt voor het zoeken naar informatie.<\/p>\n

Maar QIWI, hoewel het de geest van een startup behoudt, is een groot bedrijf. We zijn al 12 jaar actief, en de teams veranderen: mensen gaan weg, mensen komen, nieuwe teams worden gevormd. En we ontdekten op ons domein verschillende services die we als erfgoed hadden gekregen. Sommige kwamen van ontwikkelaars uit andere teams, andere waren gewoon op een indirecte manier verbonden met de Portemonnee, dus nu is die service op onze balans. Waarom zouden we ons verdiepen in wat waar en hoe werkt? De service werkt immers en we hebben productfeatures die we absoluut moeten implementeren.<\/p>\n

Hoe het soms gaat<\/h2>\n

\nMaar op een gegeven moment ontdekken we dat de service zijn functie niet meer vervult, dat er iets kapot is \u2014 wat te doen in zo'n situatie? De service werkt gewoon niet meer. Helemaal niet. En we ontdekten dit, ten eerste, per ongeluk, en ten tweede, pas na zes maanden. Dat gebeurt. Het enige wat we wisten, was op welke virtuele machines de service draaide, waar de bronbestanden lagen, en dat was het. We doen een git clone en duiken in de gedachten van de persoon die dit enkele jaren geleden heeft geschreven, maar wat zien we? Geen gebruikelijke Spring Boot, hoewel we eraan gewend zijn, want we hebben full stack en dat soort dingen. Misschien is er een Spring Framework? Maar dat is het niet.<\/p>\n

De jongen die dit allemaal schreef, was streng en schreef alles in pure Java. Er zijn geen gangbare tools voor de ontwikkelaar, en het idee komt op \u2014 we moeten dit alles herschrijven. We hebben immers microservices, en uit elke toaster klinkt het vertrouwde: \"Jongens, microservices zijn wat jullie nodig hebben!\". Als er iets misgaat, kun je rustig iedere taal pakken en alles komt goed.<\/p>\n

Het probleem is dat we op dit moment geen klant hebben die verantwoordelijk is voor deze service. Wat waren zijn zakelijke vereisten, wat zou deze service \u00fcberhaupt moeten doen? En de service is nauw ge\u00efntegreerd in jullie bedrijfsprocessen. <\/p>\n

En nu vraag ik je, hoe eenvoudig is het om een service te herschrijven zonder de zakelijke vereisten te kennen? De service logt op een onduidelijke manier, of er metrics zijn \u2014 dat is onbekend. Wat ze zijn, als ze er zijn \u2014 dat is des te onbekender. En daarbij zijn er in de service een enorm aantal klassen met onduidelijke bedrijfslogica. Iets gaat naar een bepaalde database waarvan we ook nog niks weten. <\/p>\n

Waar te beginnen?<\/h2>\n

\nMet het meest logische \u2014 de aanwezigheid van tests. Daarin staat meestal enige logica en kun je conclusies trekken over wat er aan de hand is. Tegenwoordig is TDD trendy, maar we zien dat het vijf jaar geleden vrijwel hetzelfde was als nu: vrijwel geen unit tests, en ze vertellen ons eigenlijk helemaal niets. Behalve misschien een controle, hoe een bepaalde xml wordt ondertekend met een of ander speciaal certificaat.<\/p>\n

We couldn't make sense of the code, so we decided to check what's happening on the virtual machine. We opened the service logs and found an error related to the HTTP client\u2014a self-signed certificate embedded in the application's resources had expired. We contacted our analysts, and they requested a new certificate, which was issued, and the service is up and running again. One would think that would be the end of it. But is it? The service is operational, fulfilling a function essential to our business. We have certain application development standards, which I'm sure you have as well. For instance, not storing logs on the node in a folder, but in a storage solution like Elasticsearch, and viewing them in Kibana. We can also remember the golden metrics\u2014meaning the load on the service, the number of requests, whether it's alive or not, and how the HealthCheck is performing. At the very least, these metrics will help us know when we can safely decommission it and forget it like a bad dream.<\/p>\n

Wat te doen<\/h2>\n

\nThat's why we add this old service to the table and then look for volunteer developers who will take over the service and tidy it up: they'll write some information about the service, add links to Grafana dashboards, assembly tasks, and understand how to deploy the application, rather than just dropping files onto it via FTP. <\/p>\n

The main question is\u2014how much time will this useful volunteer activity take? One sprint for a more or less experienced developer, for example, during the 20% technical debt time. But how long did it take to grasp the entrenched logic of interacting with a certain governmental system and upgrade it to newer technologies? I can't guarantee, it could take a month or even two for the team to complete. I'm speaking from experience with current integration efforts involving some new service.<\/p>\n

Nevertheless, there is no business value output whatsoever. None. Taking the service under support and investing a little time in it is perfectly reasonable. However, after our usual rigmarole with the service, we added it to the table, provided some information about it, and maybe one day we'll rewrite it. But right now it meets our service operation standards.<\/p>\n

In conclusion, I would like to propose a plan for dealing with Legacy services. <\/p>\n

Rewriting legacy from scratch is a bad idea.<\/b>
\nNeem het gerust af, daar hoeft je niet over te twijfelen. Het is begrijpelijk dat je bepaalde voordelen ziet, maar meestal heeft niemand er behoefte aan, ook jij niet.<\/p>\n

Handleiding<\/b>
\nHaal de broncode van je applicaties naar boven, maak een handleiding waarin staat wat waar ligt en hoe het werkt, vermeld ook een projectbeschrijving (bijvoorbeeld readme.md), zodat je snel kunt begrijpen waar de logs en metrics te vinden zijn. De ontwikkelaar die na jou hieraan werkt, zal je dankbaar zijn.<\/p>\n

Verstaan van het domein<\/b>
\nAls je een domein bezit, probeer dan nauwlettend te volgen. Het klinkt clich\u00e9, maar niet iedereen houdt in de gaten of de services consistent zijn. Werken volgens \u00e9\u00e9n standaard is daadwerkelijk veel eenvoudiger.<\/p>\n

Alleen geregistreerde gebruikers kunnen deelnemen aan de enqu\u00eate. Log in<\/a><\/noindex>, alstublieft.<\/p>\n

Wat doe je met je legacy?<\/h2>\n