{"id":38521,"date":"2019-10-31T22:24:16","date_gmt":"2019-10-31T19:24:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-takie-devops\/"},"modified":"2019-10-31T22:24:16","modified_gmt":"2019-10-31T19:24:16","slug":"kto-takie-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kto-takie-devops","title":{"rendered":"Wie zijn DevOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Op dit moment is dit bijna de duurste positie op de markt. De drukte rond 'DevOps'-ingenieurs overstijgt alles wat te bedenken is, en het is nog erger met Senior DevOps-ingenieurs.
\nIk werk als leidinggevende van de afdeling integratie en automatisering, raad de Engelse afkorting eens \u2014 DevOps Manager. Weerspiegelt die Engelse afkorting onze dagelijkse werkzaamheden? Waarschijnlijk niet, maar de Russische variant is in dit geval nauwkeuriger. Gezien mijn functie is het natuurlijk nodig dat ik toekomstige teamleden interview en in het afgelopen jaar heb ik ongeveer 50 mensen gesproken, en nog eens zoveel zijn afgevallen in de voorselectie met mijn medewerkers.<\/p>\n

<\/p>\n

We zijn nog steeds op zoek naar collega's, omdat er achter het label DevOps een zeer grote laag van verschillende soorten ingenieurs schuilgaat.<\/a><\/noindex><\/p>\n

<\/p>\n

Wat hieronder staat is mijn persoonlijke mening, jullie zijn niet verplicht om het ermee eens te zijn, maar ik vermoed dat het een nieuw perspectief op het onderwerp kan bieden. Ondanks het risico om in de ongenade te vallen, publiceer ik mijn mening omdat ik vind dat deze een plek verdient.<\/p>\n

<\/p>\n

Bedrijven hebben verschillende visies op wie DevOps ingenieurs zijn en voor het snel inhuren van middelen hangen ze dit label aan iedereen. De situatie is behoorlijk vreemd, aangezien bedrijven bereid zijn om onrealistische beloningen aan deze mensen te betalen, terwijl ze meestal gewoon een tooladministrator voor hun geld krijgen.<\/p>\n

<\/p>\n

Maar wie zijn eigenlijk DevOps ingenieurs?<\/h2>\n

<\/p>\n

Laten we beginnen met de geschiedenis van zijn ontstaan \u2014 Development Operations kwam voort uit een extra stap naar optimalisatie van de samenwerking binnen kleine teams om de snelheid van productontwikkeling te verhogen, als een verwacht gevolg. Het idee was om het ontwikkelingsteam te versterken met kennis over processen en benaderingen in het beheer van de productomgeving. Met andere woorden, een ontwikkelaar moet begrijpen en weten hoe zijn product functioneert onder verschillende omstandigheden, moet weten hoe hij zijn product moet implementeren en welke kenmerken van de omgeving geoptimaliseerd moeten worden om de prestaties te verbeteren. Zo ontstonden er in de loop van de tijd ontwikkelaars met een DevOps-aanpak. DevOps-ontwikkelaars schreven bouw- en verpakkingsscripts om hun werkzaamheden en de werking van de productieomgeving te vereenvoudigen. Echter, de complexiteit van de architectuur van oplossingen en de wederzijdse invloed van de infrastructuurcomponenten begonnen na verloop van tijd de werkprestaties van de omgevingen te verslechteren, waarbij elke iteratie steeds diepgaander begrip van bepaalde componenten vereiste, wat de productiviteit van de ontwikkelaar verminderde door de extra inspanningen die nodig waren om de componenten en het afstemmen van systemen op specifieke taken te begrijpen. De kosten van een ontwikkelaar stegen, de kosten van het product samen met hem, terwijl de eisen aan nieuwe ontwikkelaars in het team stegen; zij moesten ook de verantwoordelijkheden van de 'ster' van de ontwikkeling dekken, en uiteraard werden 'sterren' steeds moeilijker bereikbaar. Het is ook vermeldenswaard dat, naar mijn ervaring, weinigen van de ontwikkelaars ge\u00efnteresseerd zijn in de specificiteit van hoe pakketten door de kernel van het besturingssysteem worden behandeld, de regels voor pakketrouting, en de aspecten van hostbeveiliging. Een logische stap was om een beheerder aan te stellen, die bekend was met deze zaken, en dergelijke verantwoordelijkheden aan hem toe te vertrouwen, wat, dankzij zijn ervaring, toeliet om dezelfde prestaties te behalen tegen lagere kosten in vergelijking met de kosten van een 'ster' van de ontwikkeling. Dergelijke beheerders werden in het team geplaatst en hun belangrijkste taak was het beheer van test- en productieomgevingen, volgens de regels van het specifieke team, met middelen die specifiek voor dit team waren toegewezen. Zo kwamen DevOps in de meeste gevallen tot stand.<\/p>\n

<\/p>\n

Gedeeltelijk of volledig, na verloop van tijd begonnen systeembeheerders de behoeften van dit specifieke ontwikkelingsteam te begrijpen, om het leven van ontwikkelaars en testers te vergemakkelijken, hoe een update uit te rollen zonder op een vrijdagavond in het kantoor te moeten blijven om deploymentfouten te verhelpen. De tijd verstreek; nu werden systeembeheerders de 'sterren' die begrepen wat ontwikkelaars willen. Om de impact te minimaliseren, begonnen beheertools op te duiken, en iedereen herinnerde zich de oude en betrouwbare methodes voor OS-isolatie, die hielpen om de beveiligingsvereisten, netwerkbeheer en de configuratie van de host als geheel te minimaliseren en, als gevolg daarvan, de vereisten voor de nieuwe 'sterren' te verlagen. <\/p>\n

<\/p>\n

Er kwam een 'geweldig' iets op de markt \u2014 docker. Waarom geweldig? Simpelweg omdat het cre\u00ebren van isolatie in chroot of jail, net als OpenVZ, niet-triviale kennis van het besturingssysteem vereiste, terwijl de tool nu in staat is om eenvoudig een ge\u00efsoleerde applicatieomgeving op een bepaalde host aan te maken met alles wat nodig is, en de macht weer terug te geven aan de ontwikkelaars, terwijl de systeembeheerder zich alleen hoefde bezig te houden met \u00e9\u00e9n host, zijn veiligheid en hoge beschikbaarheid waarborgend \u2014 een logische vereenvoudiging. Maar de vooruitgang staat niet stil en systemen worden opnieuw steeds complexer, met meer en meer componenten; \u00e9\u00e9n host voldoet niet langer aan de systeembehoeften en het is noodzakelijk om clusters op te bouwen. We keren weer terug naar systeembeheerders die in staat zijn om deze systemen op te bouwen.<\/p>\n

<\/p>\n

Cyclisch, verschijnen er verschillende systemen die de ontwikkeling en\/of administratie vergemakkelijken; er verschijnen orchestration systemen die, zolang er niet van het standaardproces wordt afgeweken, eenvoudig te gebruiken zijn. Microservicesarchitectuur is ook ontstaan met het doel alles hierboven beschreven te vereenvoudigen \u2014 minder onderlinge afhankelijkheden, eenvoudiger te beheren. In mijn ervaring heb ik niet de volledige microservicesarchitectuur meegemaakt; ik zou zeggen 50-50 \u2014 50 procent microservices, zwarte dozen, wat erin kwam werd verwerkt, en de andere 50 \u2014 een gescheurde monolith, diensten die niet afzonderlijk van andere componenten konden functioneren. Dit legt opnieuw beperkingen op aan het kennisniveau van zowel ontwikkelaars als beheerders.<\/p>\n

<\/p>\n

Dergelijke 'schommelingen' van expertiseniveaus van een bepaalde bron duren nog steeds voort. Maar we zijn even afgeleid, er zijn verschillende punten die het waard zijn om belicht te worden.<\/p>\n

<\/p>\n

Build Engineer\/Release Engineer<\/h2>\n

<\/p>\n

Zeer gespecialiseerde ingenieurs die zijn ontstaan als een middel om de processen van softwarebouw en -releases te standaardiseren. Tijdens de invoering van de massale Agile-methodologie leken ze niet meer gevraagd te worden, maar dat is verre van waar. Deze specialisatie is ontstaan om specifiek de bouw en levering van software op grote schaal te standaardiseren, d.w.z. door gebruik te maken van standaardtechnieken voor alle producten van het bedrijf. Met de opkomst van DevOps hebben ontwikkelaars gedeeltelijk functies verloren, omdat juist ontwikkelaars het product voorbereiden voor levering, en gezien de veranderende infrastructuur en de benadering van zo snel mogelijke leveringen, ongeacht de kwaliteit, zijn ze in de loop der tijd precies het obstakel voor veranderingen geworden, omdat het volgen van kwaliteitsnormen onvermijdelijk de leveringen vertraagt. Zo is geleidelijk een deel van de functionaliteit van Build\/Release-ingenieurs verschoven naar de schouders van systeembeheerders.<\/p>\n

<\/p>\n

Ops zijn zo divers<\/h2>\n

<\/p>\n

We gaan verder en opnieuw duwen een breed scala aan verantwoordelijkheden en een gebrek aan gekwalificeerd personeel ons naar strikte specialisatie, als paddestoelen na de regen, verschijnen verschillende Operations:<\/p>\n

<\/p>\n