Detectie verbeteren en verspilling elimineren door middel van inventarissen en relatietracering
Naarmate uw organisatie groeit, neemt ook de hoeveelheid dingen toe die u moet bijhouden. Mogelijk moet u code, API's, containers, virtuele machines (VM's), berichtenonderwerpen, teamlidmaatschap, projecteigendom en meer bijhouden. Wanneer u schaalt, is het niet ongebruikelijk dat er vaak dubbele inspanningen worden gevonden, omdat het ene team niet op de hoogte is van het andere team. Wanneer mensen tussen teams schakelen, nieuwe mensen lid worden van het bedrijf en anderen vertrekken, kunnen projecten zwevend worden. Als dit niet wordt beheerd, kan dit leiden tot technische wildgroei en verspilling, simpelweg omdat u niet eenvoudig kunt ontdekken wat er al bestaat. Dit is een veelvoorkomende uitdaging. Bekijk bijvoorbeeld dit citaat:
We hebben een groot aantal containers of [VM-exemplaren] die worden uitgevoerd. Kunnen we onze oude VM's verwijderen? Niemand weet het. We moeten een manier bedenken om oude dingen op te schonen en de juiste tags te gebruiken, zodat we weten wie de eigenaar of het team is dat ons kan informeren over wat we kunnen doen en wat de levenscyclus is.... We weten niet of we een bepaalde VM kunnen afsluiten, omdat we niet zeker weten wat er gaat gebeuren. - Martin, DevOps Engineer, groot logistiek bedrijf
Tracering, beveiliging en hergebruik verbeteren via op maat gemaakte voorraden
Een deel van wat u nodig hebt, is een inventaris die hulp biedt bij het bijhouden van alle 'dingen' die u hebt gemaakt of gebouwd in uw ecosysteem die interne klanten op een begrijpelijke manier kunnen visualiseren.
Een inventaris kan de beveiliging verbeteren, hergebruik bevorderen en detectie in het algemeen vereenvoudigen. Azure-implementatieomgevingen beschrijven en volgen bijvoorbeeld complexe infrastructuur die is gemaakt via infrastructuur als code (IaC) als een abstracte omgeving die zich op een niveau bevindt dat zowel de ontwikkeling als de bewerkingen kunnen begrijpen. Op dezelfde manier biedt Azure API Center ontwikkelaars een manier om API's te detecteren en te gebruiken. Pakketregisters zoals GitHub Packages of Azure Artifacts (of andere inventarisaties van goedgekeurde pakketten en SDK's) verbeteren de beveiliging van de toeleveringsketen. Elk van deze hulpprogramma's biedt een inventaris waarmee u afval kunt beheren, bijhouden en opschonen.
Bij het evalueren van hoe u deze inventarissen maakt of toepast, is een belangrijke beslissing om te bepalen hoe breed de inhoud ervan moet worden weergegeven. Houd er rekening mee dat er hier geen goed of fout antwoord is. Sommige bedrijven hanteren een open keukenbenadering waarbij "iedereen het voedsel kan zien dat wordt bereid, maar slechts een paar mensen kunnen het koken." Met een open keuken hebben ontwikkelaars volledige zichtbaarheid van de softwareassets, maar kunnen ze alleen de assets wijzigen waarvoor ze verantwoordelijk zijn. Omgekeerd kunnen gereguleerde bedrijven strengere regels hebben, waarbij zelfs zichtbaarheid van projectnamen als gevoelig wordt beschouwd.
Detectie en tracering via relaties verbeteren
Het hebben van een of meer inventarissystemen die u helpen bij het bijhouden van wat u hebt, is essentieel voor platformengineering en het voorkomen van technische wildgroei. In eerste instantie kan het voldoende zijn om een set met platte inventarislijsten te hebben. Hoewel u niet vereist bent om te beginnen, kunt u de vindbaarheid ook verbeteren door relaties tussen verschillende activa in meerdere voorraden toe te voegen. Ongeacht het niveau van zichtbaarheid dat u nodig hebt, kunnen teams met een gecentraliseerd aggregatiepunt snel alle beschikbare assets zoeken en ontdekken. Dit bevordert hergebruik, vermindert de redundantie en zorgt voor een consistente benadering van governance.
Houd rekening met de relatie tussen een API-definitie en de geïmplementeerde toepassingscode waarmee de interface wordt geïmplementeerd. Deze code wordt opgeslagen in een opslagplaats en beheerd door een team en biedt documentatie over het gebruik ervan. Ontwikkel-, test-, prod- en zelfs tijdelijke sandbox-omgevingen worden gemaakt. In cloudeigen scenario's kunnen de omgevingen worden geïmplementeerd in een gedeeld Kubernetes-cluster. Het ontwikkelteam dat de API bouwt en eventuele interne gebruikers van de API moeten informatie kunnen krijgen over elk van deze dingen, maar het is niet duidelijk hoe de resources zich verhouden.
Om te beginnen kunt u zoiets eenvoudigs als een wikipagina gebruiken om bij te houden hoe elk ding zich tot elkaar verhoudt. Maar documentatie veroudert snel en kan moeilijk zijn, zowel het vinden als parseren. In het ideale scenario hebt u een systeem met een relatiegrafiek waarmee gebruikersinterfaces deze relaties in uw inventaris kunnen doorlopen. Als u de vindbaarheid echt wilt verbeteren, moet u items die zijn opgeslagen in meerdere typen inventarissen of grafieken aan elkaar kunnen koppelen. Mogelijk hoeft u voorraden niet rechtstreeks te gebruiken, maar u wilt deze waarschijnlijk wel kunnen koppelen aan informatie in een API-catalogussysteem.
Als u de digitale winkelanalogie wilt gebruiken, kan het ook handig zijn om de items (sjablonen) in uw catalogus te koppelen aan de resulterende inventarisinhoud. Als u zich bijvoorbeeld realiseert dat een van uw sjablonen een onveilige configuratie maakt, moet u snel alle resources vinden die met de sjabloon zijn gemaakt om deze op te lossen. Zelfs juiste toepassingssjablonen zijn in feite starterkitbundels in deze catalogus die zijn gekoppeld aan andere typen catalogusitems (zoals IaC-sjablonen). Als u deze koppelingen bijhoudt, kunt u proactief elke toepassing vinden die verwijst naar een ongeldige IaC-sjabloon, zelfs als er nog geen infrastructuur is ingericht.
Een vereenvoudigde variant van deze conceptuele grafiek voor ontwikkelaarsplatforms op hoog niveau is te vinden in een aantal toolkits en producten, maar hoe het wordt genoemd, varieert. De opensource-portal-toolkit Backstage.io noemt dit bijvoorbeeld een softwarecatalogus, terwijl andere producten andere termen gebruiken. De meeste van deze producten en toolkits gaan er echter van uit dat u hun bredere functieset gebruikt en vereisen dat de inhoud van uw voorraden erin wordt gedupliceerd. Deze duplicatie betekent dat de inhoud van de catalogusdatabase niet gebruikersspecifiek is, verouderd kan raken en niet wordt beheerd door de mechanismen voor gebruikersautorisatie van het werkelijke bronsysteem. Dit kan echter prima werken voor uw organisatie als u een open keukenbenadering volgt.