Ontwikkelaars in staat stellen via selfservice met kaders
Selfservice met kaders is het principe om ontwikkelteams in staat te stellen hun eigen beslissingen te nemen binnen een set goed gedefinieerde parameters, of kaders, die worden vastgesteld en goedgekeurd door de belangrijkste belanghebbenden. Belanghebbenden kunnen beveiligings-, operationele en architectuurteams in de hele organisatie zijn.
Het idee achter selfservice met kaders is dat ontwikkelteams het gewenste niveau van autonomie kunnen behouden om zelfstandig ontwikkelingsbeslissingen te nemen, terwijl automatisering en beleid belanghebbenden helpen ervoor te zorgen dat beveiliging, naleving, bewerkingen, standaarden en kosten correct worden beheerd. Het inschakelen van deze automatisering vereist samenwerking tussen teamlijnen, zodat ontwikkelaars, operators en specialisten meer kunnen doen, zonder dat dit ten koste gaat van de benodigde governance. In combinatie met verbeterde detectie en hergebruik binnen door de organisatie gedefinieerde kaders, kunnen ontwikkelaars zich zo snel mogelijk richten op het leveren van bedrijfswaarde.
[We vertellen ontwikkelaars, maak je geen zorgen over hoe het allemaal werkt, schakel ze gewoon in of uit, vul het in, zet een tekenreeks in wat je moet doen en het is eigenlijk selfservice in dat opzicht waar ze een leesmij-bestand hebben en ze invoer, uitvoer hebben en ze kunnen invoeren wat ze willen. - Daniel, Cloud Engineer, Fortune 500 Media Company
Het doel van het bieden van een selfservice-ervaring voor uw geplaveide paden is om de problemen van ontwikkelaars te verminderen en tegelijkertijd inzicht te bieden aan ontwikkelteams, bewerkingen en beheer. Het idee is dat u voor een bepaalde taak een ervaring maakt met een minimale leercurve, deels dankzij de onderliggende mogelijkheden voor automatisering en gegevensaggregatie. Naast activiteiten zoals het inrichten van infrastructuur kunnen deze ervaringen toegang bieden tot kritieke mogelijkheden voor waarneembaarheid, beleid, incidentbeheer en meer. Het idee breidt zich uit tot het detecteren en delen van interne API's, SDK's, samen met gedeelde hulpprogramma's en services. Deze ervaringen verminderen de overhead, zodat ontwikkelteams zich kunnen richten op het voor elkaar krijgen van dingen.
De tijd die nodig is om aan de slag te gaan met een project of taak is een andere motiverende factor voor selfservice-ervaringen. Een analogie die vaak wordt gebruikt voor een intern ontwikkelaarsplatform is dat het vergelijkbare mogelijkheden biedt als business-to-business digitale winkels. Digitale winkels zijn inherent ontworpen om hun klanten zelf te helpen. Ze kunnen meer doorvoer verwerken dan traditionele webwinkels, omdat ze manieren bieden om interessante items te ontdekken en te vervullen zonder met iemand te hoeven praten. Op basis van deze analogie zijn ontwikkelaars de klant en biedt het interne ontwikkelaarsplatform vergelijkbare selfservice-ervaringen. Net als bij een detailhandelaar, operators, platformtechnici en andere rollen kunnen ontwikkelaars vervolgens een catalogus met items instellen die zijn ontworpen om aan de kaders van de organisatie te voldoen.
U kunt er bijvoorbeeld aan denken dat een ontwikkelaar toegang tot een nieuw hulpprogramma aanvraagt alsof deze een digitale bestelling in de winkel plaatst. Net als bij een order wil de ontwikkelaar, zodra de aanvraag is ingediend, de voortgang kunnen bijhouden en weten wanneer deze is voltooid. Achter de schermen moet de aanvraag automatisch worden doorgestuurd naar de juiste fulfillmentprovider om aan de behoeften te voldoen. U kunt een van uw CI/CD-systemen (continue integratie en levering) beschouwen als één fulfillmentprovider, een GitOps-hulpprogramma of een prescriptief toepassingsplatform als een tweede, en een hulpprogramma voor werkstroomautomatisering voor handmatige processen als een derde. In alle gevallen kan de ontwikkelaar items uit een goed gedefinieerde catalogus op dezelfde manier zelf bedienen.
Zie Software Engineering-systemen toepassen en Een selfservicebasis voor ontwikkelaars ontwerpen voor meer informatie over het implementeren van deze concepten.
Het alles als codepatroon gebruiken
Het gebruik van infrastructuur als code (IaC) via CD-pijplijnen (continue levering) en GitOps-hulpprogramma's is een belangrijk onderdeel van het inschakelen van selfservice. Hiermee kunt u Bicep-, Terraform-, Helm-grafieken en andere hulpprogramma's gebruiken om cloudresources op aanvraag te maken en te vernietigen. Omdat de configuratie van uw cloudinfrastructuur wordt beheerd op dezelfde wijze als code in een broncodeopslagplaats, kunt u inherent alle voordelen van een Git-opslagplaats toepassen, zoals beveiliging en controlebaarheid.
Platform engineering-teams kunnen profiteren van IaC bij het inrichten van gemeenschappelijke infrastructuur en hulpprogramma's, maar dat is niet het enige voordeel van een IaC-benadering. U kunt het patroon 'als code' aanpassen voor andere scenario's, waaronder beveiliging als code en beleid als code (via hulpprogramma's zoals Azure Policy en Open Policy Agent). Volgens deze techniek wordt een configuratiebestand, meestal YAML of JSON, naar de opslagplaats gepusht. Op dat moment wordt een werkstroom geactiveerd waarmee het bestand wordt verwerkt. Deze bestanden kunnen een app-opslagplaats zijn, zoals dependabot.yml of CODEOWNERS, of ze kunnen worden onderhouden in een afzonderlijke centrale opslagplaats. U kunt dit zelfs uitbreiden naar uw eigen scenario's om alles als code (EaC) echt te realiseren.
Ontwikkelaars kunnen naar elk van deze EaC-sjablonen verwijzen met een centrale catalogus die uw selfservice-ervaringen mogelijk maakt en standaard aanbevolen procedures aanmoedigt.
Meer informatie over het codepatroon alles als.
Sjablonen voor het juiste begin maken & beheer voor rechts blijven tot stand te brengen
We bouwen modules uit voor onze [ontwikkelaars]... Dus in plaats van te hoeven schrijven of zich zorgen te maken over een van de back-ends zelf, hoeven ze zich alleen maar zorgen te maken over hun toepassingscode. - Daniel, Cloud Engineer, Fortune 500 Media Company
Bij softwareontwikkeling streven we bij het ontwerpen van toepassingen naar inkapseling, modulariteit en samenstelbaarheid. U moet deze zelfde denkwijze toepassen op platformengineering door middel van sjablonen. U kunt bijvoorbeeld een set centraal beveiligde, herbruikbare IaC-sjablonen maken en gebruiken als bouwstenen voor infrastructuur.
Deze kunnen worden gecombineerd in een op maat gemaakte toepassingssjabloon die naar deze en andere elementen verwijst als bouwstenen voor code (EaC) en die andere activiteiten omvat, zoals het maken van een opslagplaats voor broncode, het seeden van voorbeeldcode of het verstrekken van configuratie- en voorbeeldcode voor aanbevolen hulpprogramma's voor waarneembaarheid. Deze IaC-, EaC- en toepassingssjablonen kunnen vervolgens worden opgeslagen of waarnaar kan worden verwezen vanuit een centrale, beveiligde locatie, zoals een opslagplaats, de catalogus in Azure Deployment Environments (ADE) of Azure Container Registry (ACR) voor cloudeigen.
Wanneer juiste beginsjablonen worden gecombineerd met geautomatiseerde governance, scannen en beleidsconfiguratie, kunnen ze ontwikkelaars helpen om vanaf de eerste dag te blijven.
Juiste sjablonen starten
Toepassingssjablonen kunnen worden gebruikt om uw gedefinieerde geplaveide paden op te starten voor verschillende belangrijke beslissingen en acties die ontwikkelaars in de loop van een project nemen. Deze juiste sjablonen moeten veilige, beheerde ontwikkelprocedures tot stand brengen en ontwikkelaars in staat stellen snel aan de slag te gaan door automatisering in te schakelen die toegang biedt tot de hulpprogramma's die ze nodig hebben, CI/CD-pijplijnen configureert, de infrastructuur en toepassingsstack in richt en een opslagplaats configureert die volledig is uitgerust met de broncode van de ketelplaat die de benodigde SDK's of verwijzingen naar API's bevat.
Door deze toepassingssjablonen te laten verwijzen naar andere gecentraliseerde sjablonen (bijvoorbeeld IaC-sjablonen), kan elk van deze afzonderlijke bouwstenen eigen sjablonen worden om het gebruik in bestaande toepassingen te stroomlijnen. Deze sjablonen zijn van centraal belang bij het inschakelen van selfservice-ervaringen, omdat hiermee niet alleen de uitvoer wordt gedefinieerd, maar ook de beschikbare opties waaruit ontwikkelaars kunnen kiezen.
Beheer op de juiste plaats houden
Sjablonen moeten echter meer doen dan alleen een bootstrapping van een ontwikkelingsinspanning. Ze moeten ook de controle en governance vaststellen door middel van beleid en beveiligingsscans die nodig zijn om in de loop van de projectlevenscyclus te blijven. Een ander voorbeeld is dat sjablonen regels voor vertakkingsbeveiliging kunnen instellen om te voorkomen dat niet-geautoriseerde samenvoegingen in productie worden voorkomen. Omdat sjablonen best practices en algemene configuraties vastleggen, zijn ze een van de belangrijkste technieken voor het optimaliseren van de kosten voor hulpprogramma's, leveranciers en teams.
De juiste campagnes krijgen
Ten slotte kunt u, naarmate uw vertrouwen in uw verharde paden toeneemt, de onderliggende afzonderlijke bouwstenen gebruiken die u in uw toepassingssjablonen hebt geassembleerd om bestaande toepassingen naar een verhard pad te verplaatsen. Omdat uw interne klanten de waarde van uw uitgeteste verharde paden al zien, kunt u een interne get right-campagne uitvoeren om een tweerichtingsdialoog te maken met andere toepassingsteams. Ontwikkelaars kunnen leren hoe ze hun toepassing kunnen migreren, terwijl het platformengineeringsteam tegelijkertijd meer leert over het verbeteren van het platform voor hen.
Meer informatie over het starten van juiste sjablonen met behoud van beheer.
Uw eigen reis in kaart brengen
Gezien de breedte van de ervaringen die uw selfservicemogelijkheden kunnen omvatten, is het een belangrijke focus voor uw investeringsinspanningen en plan en prioriteit , zodat uw interne ontwikkelaarsplatform incrementeel waarde levert. Het traject van elke organisatie bij het maken van een intern ontwikkelaarsplatform zal anders zijn en door een productmentaliteit te volgen, kunt u zich richten op de meest kritieke plaatsen die eerst selfservice-ervaringen nodig hebben.
Meer informatie over het in kaart brengen van een platform-engineeringtraject.