Det är svårt att välja en intern utvecklarportal, men Port gjorde det enkelt

Även om en plattform löser många saker finns det fortfarande ett behov av att minska inkonsekvenser i verktyg, arbetsflöden och liknande. Dessa kan bli en betydande kognitiv belastning för mjukvaruutvecklare som egentligen vill fokusera på sitt lösningsområde. I de flesta fall behöver komplexa äldre lösningar döljas, arbetsflöden abstraheras och liknande. Det kan göras genom att skapa egna interna abstraktioner ovanpå en mängd olika verktyg, men alla organisationer har inte tid eller budget att ge sig in i ett sådant projekt. Här kommer styrkan i en bra och flexibel intern utvecklarportal in i bilden.

Under många år har jag starkt förespråkat att bygga plattformen innan man introducerar en portal, men jag har ändrat uppfattning. Portalen kan vara det första steget mot att bygga en bra plattform. Vad som bör komma först beror på portalen, organisationen, kulturen och plattformsteamets förmåga.

Vad kännetecknar en bra utvecklarportal?

Min uppfattning är att många organisationer har lagt till en utvecklarportal eftersom de sett andra göra det. Ofta leder det till en inaktuell portal som ligger undanskymd utan innehåll, och ingen anpassar den efter verksamhetens behov. Har du tur finns det kanske en halvt ifylld tjänstekatalog och ett proof of concept-arbetsflöde. Det är inte så en utvecklarportal ska sluta sin resa.

En utvecklarportal bör vara utvecklarens självklara utgångspunkt, eller, om du är lika gammal som jag, webbläsarens startsida. Den ska vara en levande webbplats som lyfter fram all information en utvecklare behöver för att komma igång med dagen. Därav namnet utvecklarportal, inte portal för inaktuell data.

Vad behövs?

Förbättrad Developer Experience (DX)

Först och främst bör du se till att utvecklarna inte behöver leta igenom flera verktyg, repositories och YAML-filer. Du bör använda ett tydligt språk som utvecklingsteamen förstår, och det borde inte vara någon överraskning att alla utvecklare inte behärskar Terraform, YAML eller liknande som används för att sätta upp infrastruktur.

Smidig integration med din stack

Ofta är det svårt att dra nytta av alla bra delar i en portal eftersom du behöver skriva egna komponenter för att se till att allt följer portalens struktur. Ett bättre alternativ låter dig mappa dina verktygs API:er till portalen, så att du kan lägga mer tid på att skapa en riktigt bra DX.

Enkel styrning

Genom att använda golden paths som fungerar som arbetsflöden när du behöver skapa en ny tjänst eller applikation. Med dashboards som visar resultat från nyliga sårbarhetsskanningar och hur du kan åtgärda dem, om arbetet ännu inte har flyttats över till AI.

Resultat och kostnader nära till hands

För många stora organisationer är det viktigt att känna till driftskostnaderna för tjänster och applikationer. En utvecklarportal kan hjälpa dig att koppla samman kostnader och tjänsteprestanda för att visa om dina tjänster drivs på ett ekonomiskt ansvarsfullt sätt.

Om det låter som ett mödosamt arbete att uppfylla förväntningarna på en utvecklarportal, och du redan funderar på att rekrytera ett team enbart för att driva portalen, bör du förmodligen fundera på om du har rätt verktyg för uppgiften. En bra portal har låg driftsbelastning och bör vara ett verktyg du använder, inte något du bygger själv i dag. Det kan finnas situationer i reglerade branscher där du inte har det valet, men då är du sannolikt redan van vid att behöva lägga till mer resurser än organisationer som enkelt kan använda publika moln.

Läs mer i det här blogginlägget: Att välja klokt: en guide för att välja intern utvecklarportal

Därför är jag entusiastisk över Port

Med tanke på variationen av utvecklarportaler jag har sett genom åren har det varit komplicerat att avgöra vilken som passar kunden bäst. Även om inget verktyg passar alla, Port.io tillhör toppskiktet när jag rekommenderar en utvecklarportal.

Vad gör Port speciellt?

Datamodellering

När du börjar med Port fokuserar du på att definiera blueprints, som är de grundläggande byggblocken i din portal. Varje blueprint består av egenskaper som du kan fylla med data från dina olika integrationer. Bäst av allt är att du inte behöver bygga modellen i deras UI – du kan skripta modellen via deras API eller använda Terraform eller Pulumi.

Integration med dina verktyg

Det finns en hel del fördefinierade blueprints och integrationer som täcker större delen av din verktygskedja direkt. Om du inte hittar det verktyg du vill använda finns ett öppet ramverk för att bygga egna integrationer.

Lägre driftskostnader

Eftersom Port endast erbjuds som SaaS tillkommer inga dolda kostnader för att underhålla och uppgradera portalen när nya versioner släpps.

Tillgängligt för alla

Utvecklarportalen är ofta ett verktyg för utvecklaren, men Port går ännu längre. Utifrån behoven hos era olika användargrupper kan ni utforma sidor och dashboards efter behov. Utvecklaren kan se en säkerhetspoäng för sin applikation, SRE:er kan få en övergripande bild av alla applikationer som körs och CISO:n kan få en aggregerad översikt.

Redo för enterprise

Med detaljerad åtkomstkontroll, granskningsloggar, policyer och dashboards får du alla insikter som förenklar arbetet med styrning och regelefterlevnad.

Jämfört med Backstage minskar Port tiden till värde avsevärt, eftersom det är en komplett portal och inte ett ramverk för att bygga en.

Avslutande tankar

Att välja rätt portal har blivit enklare för organisationer tack vare att Port har lanserat ett verktyg för Platform Engineering som stödjer flera delar av organisationen. Det handlar inte bara om att ge utvecklare rätt förutsättningar, utan omfattar även fler användargrupper och passar de verktyg och arbetsflöden som plattforms- och driftteam använder varje dag.

Port är verktyget jag önskar att vi hade haft för flera år sedan. Men nu är det äntligen här, redo att stärka din verksamhet och minska friktionen i det dagliga arbetet.