Dela via

Förfina programplattformen för att effektivisera utvecklings- och infrastrukturhanteringen

En stor del av att förbättra organisationens plattformstekniker är att utvärdera din programplattform. En programplattform innehåller alla verktyg och tjänster som används för utveckling, distribution och programhantering i din organisation.

Förenkla och standardisera

Infrastruktur som kod (IaC) och automatiseringsverktyg kan kombineras med mallar för att standardisera infrastruktur- och programdistribution. För att minska belastningen på plattformsspecifika uppgifter för slutanvändaren kan du abstrahera plattformsinformation genom att dela upp val i relaterbara namngivningskonventioner, till exempel:

  • Resurstypkategorier (hög beräkning, högt minne)
  • Resursstorlekskategorier (till exempel storlek på t-shirtar i små, medelstora och stora)

Mallar bör representera allmänna krav som har testats med förinställda konfigurationer, så att utvecklingsteam omedelbart kan komma igång med att tillhandahålla minimala parametrar och utan att behöva granska alternativen. Det finns dock tillfällen då team behöver ändra fler alternativ för publicerade mallar än vad som är tillgängligt eller önskvärt. En godkänd design kan till exempel behöva en specifik konfiguration som är utanför standardinställningarna för mallen som stöds. I det här fallet kan drift- eller plattformstekniker skapa en engångskonfiguration och sedan bestämma om mallen behöver införliva dessa ändringar som standard.

Du kan spåra ändringar med hjälp av IaC-verktyg med driftidentifieringsfunktioner som automatiskt kan åtgärda drift (GitOps). Exempel på dessa verktyg är Terraform - och molnbaserade IaC-verktyg (till exempel Kluster-API, Korsplan, Azure Service Operator v2). Utanför IaC-verktygsavdriftsidentifiering finns det molnkonfigurationsverktyg som kan fråga efter resurskonfigurationer, till exempel Azure Resource Graph. Dessa kan fungera som två fördelar; för att övervaka ändringar utanför infrastrukturkoden och granska för ändrade förinställda konfigurationer. För att undvika att vara för strikt kan du implementera toleranser även i distributioner med fördefinierade gränser. Du kan till exempel använda Azure Policy för att begränsa antalet Kubernetes-noder som en distribution kan ha.

Självhanterad eller administrerad?

I offentliga moln har du möjlighet att använda programvara som en tjänst (Saas), paaS (plattform som en tjänst) eller infrastruktur som en tjänst (IaaS). Mer information om SaaS, PaaS och IaaS finns i utbildningsmodulen Beskriv molntjänsttyper. PaaS-tjänster erbjuder effektiva utvecklingsupplevelser men är mer normativa med sina appmodeller. I slutändan finns det en kompromiss mellan användarvänlighet och kontroll som du behöver utvärdera.

Under plattformsdesignen utvärderar och prioriterar du organisationens tjänstbehov. Om du till exempel skapar appar direkt på Azure Kubernetes Service (AKS) eller via Azure Container Apps beror på dina krav för tjänsten och på din interna kapacitet och kompetensuppsättning. Detsamma gäller för funktionsliknande tjänster som Azure Functions eller Azure App Service. Container Apps, Functions och App Service minskar komplexiteten, medan AKS ger mer flexibilitet och kontroll. Fler experimentella appmodeller som Radius OSS-inkubationsprojektet försöker ge en balans mellan de två, men är i allmänhet i tidigare mognadsstadier än molntjänster med fullt stöd och närvaro i etablerade IaC-format.

De problem som du identifierade under planeringen bör hjälpa dig att utvärdera vilken del av den här skalan som passar dig. Var noga med att ta hänsyn till din egen interna befintliga kompetensuppsättning när du fattar ett beslut.

Delade eller dedikerade resurser

I din organisation finns det resurser som kan delas av flera program för att öka användningen och kostnadseffektiviteten. Varje delad resurs har en egen uppsättning överväganden. Det här är till exempel överväganden för att dela Kubernetes-kluster, men vissa gäller för andra typer av resurser:

  • Organisation: Att dela resurser som kluster inom, snarare än över, organisatoriska gränser kan förbättra hur de överensstämmer med organisationens riktning, krav och prioritering.
  • Applikationstillämpning: Applikationer kan ha olika krav på hyresgästanpassning; du måste granska enskilda applikationers säkerhet och regelefterlevnad om de kan samexistera med andra applikationer. I Kubernetes kan till exempel program använda namnområdesisolering. Men du bör också överväga programinnehavare för olika miljötyper. Det är till exempel ofta bäst att undvika att blanda testprogram med produktionsprogram i samma kluster för att undvika oväntade effekter på grund av felkonfigurationer eller säkerhetsproblem. Eller så kan du välja att först testa och finjustera dedikerade Kubernetes-kluster för att spåra dessa problem innan du distribuerar i ett delat kluster i stället. Oavsett är konsekvens i din strategi nyckeln till att undvika förvirring och misstag.
  • Resursförbrukning: Förstå varje programs resursanvändning och outnyttjade kapacitet och gör en prognos för att uppskatta om delning är genomförbart. Du bör också vara medveten om gränserna för de resurser som förbrukas (datacenterkapacitet eller prenumerationsgränser). Målet är att undvika att flytta ditt program och beroenden på grund av resursbegränsningar i en delad miljö, eller att ha liveplatsincidenter när kapaciteten tar slut. Använd resursgränser, representativ testning, övervakning av aviseringar och rapportering för att identifiera resursförbrukning och skydda mot program som förbrukar för många resurser.
  • Optimera delade konfigurationer: Delade resurser som delade kluster kräver extra hänsyn och konfiguration. Dessa överväganden omfattar korsladdning, resursallokering, behörighetshantering, ägarskap för arbetsbelastning, datadelning, uppgraderingssamordning, arbetsbelastningsplacering, etablering, hantering och iterering av en baslinjekonfiguration, kapacitetshantering och arbetsbelastningsplacering. Delade resurser har fördelar, men om standardkonfigurationerna är för restriktiva och inte utvecklas blir de föråldrade.

Implementera styrningsstrategier

Styrning är en viktig del av att aktivera självbetjäning med skyddsmekanismer, men att tillämpa efterlevnadsregler på ett sätt som inte påverkar tid till affärsvärde för program är en vanlig utmaning. Det finns två delar av styrningen:

  • Inledande distributionsefterlevnad (start höger): Detta kan uppnås med standardiserade IaC-mallar som görs tillgängliga via kataloger, med behörighetshantering och principer för att säkerställa att endast tillåtna resurser och konfigurationer kan distribueras.
  • Upprätthålla efterlevnad (håll dig rätt): Principbaserade verktyg kan förhindra eller varna dig när det finns resursändringar. Utöver din kärninfrastruktur bör du överväga att verktyg även stöder efterlevnad i resurser som Kubernetes tillsammans med operativsystemet som används i dina containrar eller virtuella datorer. Du kanske till exempel vill framtvinga en låst os-konfiguration eller installera säkerhetsprogramverktyg som Windows-grupprincip, SELinux, AppArmor, Azure Policy eller Kyverno. Om utvecklare bara har åtkomst till IaC-lagringsplatser kan du lägga till arbetsflöden för godkännande för att granska föreslagna ändringar och förhindra direkt åtkomst till resurskontrollplan som Azure.

För att upprätthålla efterlevnaden krävs verktyg för att komma åt, rapportera och agera i problem. Azure Policy kan till exempel användas med många Azure-tjänster för granskning, rapportering och reparation. Den har också olika lägen som Granskning, Neka och DeployIfNotExists beroende på dina behov.

Även om principer kan framtvinga efterlevnad kan de också oväntat orsaka problem med applikationer. Överväg därför att övergå till en policy som kod (PaC) när du arbetar i stor skala. Som en viktig del av din start-rätt och stanna-rätt metod tillhandahåller PaC:

  • Centralt hanterade standarder
  • Versionskontroll för dina policyer
  • Automatiserad testning och validering
  • Kortare tid att distribuera
  • Kontinuerlig distribution

PaC kan bidra till att minimera påverkansområdet för en potentiellt felaktig policy med funktioner som:

  • Principdefinitioner som lagras som kod på en lagringsplats som granskas och godkänns
  • Automatisering för att tillhandahålla testning och validering
  • Ringbaserad gradvis distribution av principer och reparation av befintliga resurser bidrar till att minimera explosionsradien för potentiellt dåliga principer
  • Åtgärdsuppgiften har inbyggd säkerhet, med funktioner såsom att stoppa åtgärdsaktiviteten om mer än 90 procent av utplaceringarna misslyckas

Implementera rollspecifik observerbarhet och loggning

För att stödja dina program och infrastruktur behöver du observerbarhet och loggning i hela stacken.

Skärmbild av en Grafana-instrumentpanel som visar observerbarhet och loggning.

Kraven skiljer sig åt per roll. Till exempel kräver plattformstekniker och driftteam instrumentpaneler för att granska infrastrukturens hälsa och kapacitet med lämpliga aviseringar. Utvecklare kräver programmått, loggar och spårningar för att felsöka och anpassa instrumentpaneler som visar programmets och infrastrukturens hälsa. Ett problem som någon av dessa roller kan stöta på är kognitiv överbelastning från för mycket information eller kunskapsluckor på grund av brist på användbar information.

Tänk på följande för att lösa dessa utmaningar:

  • Standarder: Använd loggningsstandarder för att göra det enklare att skapa och återanvända standardiserade instrumentpaneler och förenkla bearbetning av inmatning via något som liknar opentelemetry-ramverket för observerbarhet.
  • Behörigheter: Tillhandahåll instrumentpaneler på team- eller programnivå med hjälp av något som Grafana för att tillhandahålla samlade data för alla intresserade, tillsammans med en möjlighet för betrodda medlemmar i programteam att på ett säkert sätt få åtkomst till loggar vid behov.
  • Lagring: Att behålla loggar och mått kan vara dyrt och kan skapa oavsiktliga risker eller efterlevnadsöverträdelser. Upprätta standardinställningar för arkivering och publicera dem som en del av vägledningen för en bra start.
  • Övervaka resursgränser: Driftteam bör kunna identifiera och spåra eventuella begränsningar för en viss typ av resurs. Dessa begränsningar bör beaktas i IaC-mallar eller -principer med hjälp av verktyg som Azure Policy. Operationer bör sedan proaktivt övervaka med hjälp av instrumentpaneler i något som Grafana och skala upp gemensamma resurser där automatiserad skalning inte är möjlig eller aktiverad. Du kan till exempel övervaka antalet Kubernetes-klusternoder för kapacitet när appar registreras och ändras över tid. Aviseringar behövs och dessa definitioner bör lagras som kod så att de kan läggas till programmatiskt i resurser.
  • Identifiera nyckelkapacitet och hälsomått: Övervaka och varna operativsystem och delade resurser (till exempel CPU, minne och lagring) för svält, med måttinsamling med något som liknar Prometheus - eller Kubernetes-övervakning i Azure Monitor. Du kan övervaka socketar/portar som används, förbrukning av nätverksbandbredd för chattiga appar och antalet tillståndskänsliga program som finns i klustret.

Skapa säkerhet med principen om lägsta behörighet, enhetlig säkerhetshantering och hotidentifiering

Säkerhet krävs på varje lager, från kod, container, kluster och moln/infrastruktur. Det här är de minsta rekommenderade säkerhetsstegen:

  • Följ principen om lägsta behörighet.
  • Förena din DevOps-säkerhetshantering över flera pipelines.
  • Se till att kontextuella insikter för att identifiera och åtgärda din mest kritiska risk är synliga.
  • Aktivera identifiering och respons mot moderna hot i dina molnarbetsbelastningar under drift.

För att lösa problem på det här området behöver du verktyg för att utvärdera verktyg som fungerar i dina teknik- och programsystem, resurser och tjänster i moln och hybrid (till exempel Microsoft Defender för molnet). Utöver programsäkerhet utvärderar du:

Behörighetskraven kan variera beroende på miljö. I vissa organisationer kan till exempel enskilda team inte komma åt produktionsresurser och nya program kan inte distribueras automatiskt förrän granskningarna har slutförts. Automatisk resurs- och appdistribution och åtkomst till kluster för felsökning kan dock tillåtas i utvecklings- och testmiljöer.

Det kan vara svårt att hantera identitetsåtkomst till tjänster, program och infrastruktur i stor skala. Identitetsprovidrar skapar, underhåller och hanterar identitetsinformation. Din plan bör omfatta autentiseringstjänster för program och tjänster, och tjänsten bör integreras med rbac-auktoriseringssystem (rollbaserad åtkomstkontroll) i stor skala. Du kan till exempel använda Microsoft Entra-ID för att tillhandahålla autentisering och auktorisering i stor skala för Azure-tjänster som Azure Kubernetes Service utan att behöva konfigurera behörigheter direkt i varje enskilt kluster.

Program kan behöva åtkomst till en identitet för att få åtkomst till molnresurser som lagring. Du måste granska kraven och utvärdera hur din identitetsprovider kan stödja detta på ett så säkert sätt som möjligt. I Azure Kubernetes Service kan till exempel molnbaserade appar använda en arbetsbelastningsidentitet som federeras med Microsoft Entra-ID så att containerbaserade arbetsbelastningar kan autentiseras. Med den här metoden kan program komma åt molnresurser utan hemliga utbyten i programkoden.

Minska kostnaderna genom att identifiera arbetsbelastningsägare och spåra resurser

Att hantera kostnader är en annan del av plattformstekniken. För att hantera programplattformen korrekt behöver du ett sätt att identifiera arbetsbelastningsägare. Du vill ha ett sätt att skapa en översikt över resurser som kopplas till ägare för en viss uppsättning metadata. I Azure kan du till exempel använda AKS-etiketter, Azure Resource Manager-taggar, tillsammans med begrepp som projekt i Azure Deployment Environments för att gruppera dina resurser på olika nivåer. För att detta ska fungera måste de valda metadataobjekten innehålla obligatoriska egenskaper (med något som Azure Policy) när du distribuerar arbetslast och resurser. Detta hjälper till med kostnadsallokering, resursmappning av lösningar och ägare. Överväg att köra regelbunden rapportering för att spåra överblivna resurser.

Utöver spårning kan du behöva tilldela kostnader till enskilda programteam för deras resursanvändning med samma metadata med kostnadshanteringssystem som Microsoft Cost Management. Även om den här metoden spårar resurser som etablerats av programteamen, täcker den inte kostnaden för delade resurser, såsom kostnaden för din identitetsleverantör; loggning och lagring av mått; och nätverksbandbreddsförbrukning. För delade resurser kan du dela upp driftskostnaderna bland de enskilda teamen eller tillhandahålla dedikerade system (till exempel lagring av loggar) där det finns ojämn förbrukning. Vissa delade resurstyper kanske kan ge insikter om resursförbrukning. Kubernetes har till exempel verktyg som OpenCost eller Kubecost och kan vara till hjälp.

Du bör också leta efter verktyg för kostnadsanalys där du kan granska de aktuella utgifterna. I Azure-portalen finns till exempel kostnadsaviseringar och budgetaviseringar som kan spåra förbrukningen av resurser i en grupp och skicka meddelanden när du når förinställda tröskelvärden.

Bestäm när och var du ska investera

Om du har mer än en programplattform kan det vara svårt att avgöra när och var du ska investera i förbättringar som löser problem som höga kostnader eller dålig observerbarhet. Om du börjar om från början har Azure Architecture Center flera potentiella mönster som du kan utvärdera. Men utöver det, här är några frågor att tänka på när du börjar planera vad du vill göra:

Question Råd
Vill du anpassa din befintliga programplattform, börja om eller använda en kombination av dessa metoder? Även om du är nöjd med det du har nu eller börjar om från början vill du tänka på hur du kan anpassa dig till förändringar över tid. Omedelbara förändringar fungerar sällan. Dina applikationsplattformar är ett rörligt mål. Ditt ideala system ändras när tiden går. Du vill ta med det här tänkandet och eventuella relaterade migreringsplaner i din framåtriktade design.
Om du vill ändra det du gör idag, vilka produkter, tjänster eller investeringar är du nöjd med? Som talesättet säger, "om det inte är trasigt, fixa det inte." Ändra inte saker utan anledning att göra det. Men om du har några hemodlade lösningar bör du överväga om det är dags att gå mot en befintlig produkt för att spara på långsiktigt underhåll. Om du till exempel använder en egen övervakningslösning vill du ta bort den bördan från ditt driftteam och migrera till en ny hanterad produkt?
Var ser du den största förändringen över tid? Finns något av dessa inom områden som är gemensamma för alla (eller de flesta) av din organisations apptyper? Områden som du eller dina interna kunder inte är nöjda med och som sannolikt inte kommer att ändras ofta är bra platser att börja på. Dessa har den största avkastningen på investeringar på lång sikt. Detta kan också hjälpa dig att reda ut hur du skulle underlätta migreringen till en ny lösning. Appmodeller tenderar till exempel att vara flytande, men logganalysverktyg tenderar att ha en längre hållbarhetstid. Du kan också fokusera på nya projekt och program som ska startas medan du bekräftar att riktningsändringen har önskad avkastning.
Investerar du i anpassade lösningar i områden med högst mervärde? Känner du starkt att en unik plattformsfunktion för appinfrastruktur är en del av din konkurrensfördel? Om du har identifierat luckor bör du innan du gör något anpassat överväga vilka områden leverantörerna mest sannolikt kommer att investera i och fokusera ditt anpassade tänkande någon annanstans. Börja med att tänka på dig själv som en integrerare snarare än en anpassad appinfrastruktur eller appmodellleverantör. Allt du bygger måste underhållas, vilket dvärgar direkta kostnader på lång sikt. Om du känner ett akut behov av att anpassa en lösning inom ett område som du misstänker kommer att täckas av leverantörer på lång sikt, förbered dig för avveckling eller långsiktigt stöd. Dina interna kunder är vanligtvis lika nöjda (om inte ännu mer) med en standardprodukt som med en anpassad.

Att anpassa dina befintliga programplattformsinvesteringar kan vara ett bra sätt att komma igång. När du gör uppdateringar bör du överväga att börja med nya program för att förenkla pilotidéerna innan någon form av distribution. Ta hänsyn till den här ändringen via IaC och program templating. Investera i anpassade lösningar för dina unika behov i områden med hög effekt och högt värde. Annars kan du försöka använda en färdig lösning. Precis som med ingenjörssystem, fokusera på att automatisera tillhandahållande, spårning och distribution snarare än att anta en rigid väg för att hantera förändringar på lång sikt.

Relaterat innehåll

  • Last updated on