Bygg den perfekta Internal Developer Platform för dina team

Men varför inte bara göra det? Vad kan gå fel?

Precis som i många andra projekt är det svåraste att komma igång – och att börja på rätt sätt. Men det räcker inte: en plattform måste färdigställas och användas trots alla hinder.

I det här blogginlägget besvarar jag följande frågor:

1. Hur börjar du bygga en plattform?

2. Hur utformar du dess arkitektur?

3. Vilka utmaningar kommer du att möta? Hur kan de övervinnas?

Så börjar du bygga en plattform

Så hur gör du en plattform till verklighet? Att etablera en IDP omfattar tre huvudsteg:

1. Definiera arkitekturen och programvaruverktygen

För att skapa en plattform behöver du göra några viktiga arkitektoniska och tekniska val. Utöver utvecklarportalen kretsar de flesta plattformar kring Kubernetes, som sätter ramarna för de abstraktioner och principer som används av de olika programvarukomponenterna.

2. Integrera komponenter och lägg till funktionalitet

När plattformens kärna är på plats är det dags att samla de olika komponenterna. Integrering handlar om mer än att koppla källkoden till build-pipelines. Det handlar också om att införa åtkomstkontroller och säkerställa regelefterlevnad. Du behöver till exempel ofta bygga in säkerhetsskanning och automatiserade kvalitetsgrindar i din IDP.

3. Gör utvecklarna till en del av plattformen

Med hjälp av guider och handledningar kan utvecklarna börja använda plattformen så snart den är tillräckligt mogen. De kan ge tidig återkoppling på funktionaliteten och efterfråga funktioner som gynnar deras arbetsflöde. En plattform har införts framgångsrikt när utvecklarna aktivt bidrar, till exempel genom att skapa mallar, skriva dokumentation och lägga till anpassade vyer på dashboarden.

Utforma plattformens arkitektur

Att definiera plattformens arkitektur är komplicerat, och det kan vara lockande att återanvända befintliga verktyg och tjänster för att få ett försprång. I många fall kan det dock vara en dålig idé. Att tänka på plattformen som den bör vara, som ett greenfield-projekt, är ett värdefullt sätt att bli av med legacy och ta till sig modern teknik. Men hur hanterar du komplexiteten? Det är bra att börja med en stabil grund och sedan fundera på vad som utgör plattformens kärna. Referensimplementationer kan också hjälpa dig att komma igång.

Cloud Native-principer

Grunden för en plattform består av de tekniska angreppssätt som den bygger på och de grundläggande komponenter som får den att fungera. Modern Cloud Native-teknik är särskilt utvecklad för att dra nytta av molnparadigmet och riktar sig specifikt till skalbara system med löst kopplade komponenter som är motståndskraftiga och säkra. Ett Cloud Native-angreppssätt för att bygga IDP:er bygger på några viktiga principer.

• Kubernetes. Utöver att vara en orkestrerare visar Kubernetes hur moderna applikationer fungerar i praktiken: en uppsättning tillståndslösa mikrotjänster implementerade med programvarucontainrar. Det gör det också enkelt att skala applikationer i molnmiljöer.

• Allt som kod. Ett system definieras som kod för alla sina komponenter, inklusive den underliggande infrastrukturen. Koden är läsbar för människor och versionshanteras, vanligtvis genom YAML-konfigurationsfiler som lagras i ett versionshanteringssystem.

• Säkerhet överallt. Åtkomst till plattformen styrs av rollbaserad åtkomstkontroll. Ömsesidig autentisering används och all data krypteras under överföring. Tokens och certifikat är kortlivade och genereras automatiskt.

Kärnkomponenter

Principerna vi har gått igenom är de grundläggande abstraktionerna för att bygga plattformar, och de har alla samma kärnkomponenter.

• Identitet och åtkomst. Gör det möjligt för användare att autentisera sig och få åtkomst till plattformen med de rättigheter som motsvarar deras roll. Vanligtvis används identitetsfederering och centraliserad åtkomsthantering.

• Infrastrukturprovisionering: Detta innebär att driftsätta och konfigurera infrastrukturen som stöder plattformens tjänster. Typisk infrastruktur omfattar Kubernetes-kluster, databaser och nätverksresurser.

• Versionshanteringssystem. Lagrar kod och spårar förändringar över tid genom att spara historik. Git är dagens de facto-standard och används för kod, konfigurationsfiler och dokumentation.

• Continuous Integration och Continuous Delivery. Gör det möjligt att bygga en applikation, genomföra olika tester och driftsätta applikationen i en målmiljö.

• Utvecklarportal. Innehåller en tjänstekatalog, mjukvarumallar och teknisk dokumentation i en samlad vy. Det är vanligtvis en dashboard som visar status för olika tjänster och erbjuder self-service-funktioner.

Referensarkitekturer

Nu känner vi till de grundläggande komponenterna i en plattform och kan välja specifik mjukvara eller specifika tjänster för var och en av dem och sedan lägga till resten. Utbudet är stort – det finns alldeles för många alternativ. Cloud Native Computing Foundation (CNCF) underhåller en översikt över open source-projekt och kommersiella produkter. Översikten kan användas som en karta för att utforska de tillgängliga alternativen, smidigt organiserade i kategorier. Den omfattar dock hundratals lösningar. Att välja de ”rätta” för din plattform kan kännas överväldigande.

Cloud Native Computing Foundation (CNCF) är ett initiativ som främjar användningen av modern teknik för att köra skalbara applikationer i molnet – till exempel mjukvarucontainrar, mikrotjänster och deklarativa programmeringsgränssnitt för applikationer. CNCF stöttar också ett ekosystem av communitydrivna open source-projekt. Organisationen underhåller bland annat en karta över dessa projekt och definierar mått för att bedöma deras mognadsgrad.

Plattformar bör anpassas efter varje organisation, men finns det några ”mallar” att utgå från? Cloud Native Operational Excellence (CNOE) strävar efter att tillhandahålla en referensarkitektur genom att samla verktygskedjor och beprövade metoder för att bygga en IDP. CNOE fokuserar på open source-lösningar och på IDP:er som kan byggas ovanpå olika molnleverantörer. CNOE:s teknikval är följande:

• Keycloak för identitets- och åtkomsthantering.

• External Secrets Operator för integration med tredjepartsvalv och hemlighetshanterare.

• Crossplane och Terraform för infrastruktur som kod.

• Argo Workflows och Tekton för Continuous Integration.

• Argo CD och Flux för Continuous Delivery.

• Backstage som utvecklarportal.

Cloud Native Operational Excellence (CNOE)

Cloud Native Operational Excellence (CNOE) är ett open source-initiativ för att bygga Internal Developer Platforms (IDP), lett av ledande företag som Adobe, Amazon Web Services, Autodesk, Salesforce och Twilio. CNOE är inte en färdig plattformslösning, utan ett initiativ för att dela utvecklarverktyg och mönster som organisationer kan använda för att skapa sina IDP:er. Som community bidrar CNOE också med verktyg och referensimplementationer som stöder olika molnleverantörer.

Utmaningarna du kommer att möta

Trots fördelarna behöver du hjälp med att etablera en plattform.

Hantera komplexitet

Att utveckla en plattform är utmanande. Många komponenter behöver integreras noggrant för att fungera som avsett, och integrationen bygger ofta på konfigurationsfiler under versionshantering. Det här arbetssättet är kraftfullt, men också något omständligt. Filerna är inte särskilt användarvänliga och kan behöva förbearbetas med specialiserade verktyg.

Ett sätt att lösa problemet är att utöka plattformens self-service-funktioner i dashboarden, så att utvecklare kan skapa resurser och inte bara visualisera dem via ett användarvänligt och välbekant webbgränssnitt.

Balansera frihet och styrning

Utvecklare kan uppfatta plattformen som ett hot – en struktur som begränsar deras frihet och stör deras arbetsflöde. Det händer oftast när plattformen saknar de funktioner som förväntas.

I sådana fall börjar utvecklarna hitta sätt att kringgå plattformen och kan till slut bygga en egen. Därför behöver du involvera utvecklare tidigt i arbetet med att bygga plattformen. Omfattande feedback från flera team är mycket värdefull för att fatta välgrundade beslut och dimensionera funktionaliteten.

Göra plattformen hållbar

När plattformen är på plats måste den kontinuerligt uppdateras, byggas ut och drivas.

Ett vanligt tillvägagångssätt är att behandla den som en produkt och etablera ett plattformsteam som stöttar den. Det kan kännas naturligt, men du riskerar att gå emot DevOps-principerna. Du separerar utveckling och drift och kan skapa en plattformssilo.

Ett sätt att hantera den här risken är att låta utvecklare bidra till plattformen, till exempel genom innersourcing – en metod för mjukvaruutveckling som tillämpar beprövade metoder från open source-projekt inom en organisation.

Avslutande tankar

Att skapa en Internal Developer Platform (IDP) är avgörande för att skala DevOps-initiativ utan att överbelasta utvecklarna, men det innebär utmaningar att både komma igång och förvalta den. Målet med det här blogginlägget var att ge en överblick över processen att bygga en IDP, från att definiera dess arkitektur till att övervinna de oundvikliga hinder som uppstår.

Du har kunskapen. Nu är det dags att komma igång!