Dela via

Förfina programplattformen

  • Artikel

När du förstår de problem som du vill ta itu med först i din plattformstekniska resa kan du upptäcka att du behöver ta itu med några utmaningar med din programplattform. Den här artikeln innehåller några tips för hur du kan göra just det. Du får lära dig mer om de ofta missade eller bortglömda aspekterna av att skapa en välarkitekterad programplattform. Mer specifikt infrastrukturhantering, säkerhet, kostnadshantering, styrning och observerbarhet.

Bestämma när och var du ska investera

Om du har en eller flera programplattformar idag kan det vara svårt att avgöra när och var du ska investera i förbättringar som löser de problem du har identifierat. 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 finns här några frågor att tänka på när du börjar planera vad du vill göra:

Fråga Tips
Vill du anpassa din befintliga programplattform, börja om på nytt 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 för att förändras över tid. Flash skärning fungerar sällan. Oavsett, precis som tekniska system, är dina programplattformar ett rörligt mål. Det du landar på idag kommer att förändras när tiden går. Du bör ta med det här tänkandet och eventuella relaterade migreringsplaner i din framåtriktade design. Läs mer om infrastruktur som redan täcks som kod (IaC) och mallmetoder i Tillämpa programvarutekniksystem som hjälper dig att hantera en del av den här variationen för nya program.
Om du vill ändra vad du gör idag, vilka produkter, tjänster eller investeringar är du nöjd med? Som ordspråket 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 inhemska 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 din 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ållbarhet. Du kan också fokusera på nya projekt/program som ska startas medan du bekräftar att riktningsändringen har önskad avkastning.
Investerar du i anpassade lösningar i områden med det högsta mervärdet? 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 i stället för en anpassad appinfrastruktur eller appmodellleverantör. Allt du bygger måste underhållas som dvärgar startkostnader på lång sikt. Om du känner ett akut behov av att anpassa en lösning i ett område som du misstänker kommer att omfattas av leverantörer på lång sikt, planera för solnedgång eller långsiktigt stöd. Dina interna kunder blir vanligtvis lika nöjda (om inte fler) med en färdig produkt som en anpassad produkt.

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 typ av distribution. Ta hänsyn till den här ändringen via IaC och programmallar. Investera i anpassade lösningar för dina unika behov i områden med hög påverkan och högt värde. Annars kan du försöka använda en färdig lösning. Precis som med tekniska system fokuserar du på att automatisera etablering, spårning och distribution i stället för att anta en fast väg som hjälper dig att hantera förändringar över tid.

Design- och arkitekturöverväganden

Det finns flera potentiella programplattformsmönster som du kan använda, men här är några vanliga områden som är viktiga, men som ofta missas under designen.

Infrastrukturhantering

Som vi nämnde i Tillämpa programvarutekniksystem kan IaC- och automatiseringsverktyg kombineras med mallar för att standardisera infrastruktur- och programdistribution. För att minska bördan för plattformsspecifika uppgifter för slutanvändaren bör du abstrahera plattformsinformation genom att dela upp alternativ i relaterbara namngivningskonventioner, till exempel:

  • Resurstypkategorier (hög beräkning, högt minne)
  • Resursstorlekskategorier (storlek på t-shirt, små medelstora och stora.)

Målet bör vara att ha mallar som representerar 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 kommer dock att finnas 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 ligger utanför standardinställningarna för den mall 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 ändringarna 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 (exempel, kluster-API, korsplan, Azure-tjänstoperatör v2). Utanför IaC-verktygets driftidentifiering finns det molnkonfigurationsverktyg som kan fråga efter resurskonfigurationer, till exempel Azure Resource Graph. Dessa kan tjäna som två fördelar; du övervakar ändringar utanför infrastrukturkoden och granskar ä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 hanterad?

I offentliga moln kan du välja att använda SaaS, PaaS eller IaaS. Mer information om SaaS, PaaS och IaaS finns i utbildningsmodulen Beskriva molnbegrepp. PaaS-tjänster erbjuder smidiga 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 de tjänster som du vill erbjuda eller flytta till. Om du till exempel skapar appar direkt på Azure Kubernetes Service (AKS) eller via Azure Container Apps (ACA) 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. ACA, Azure Functions och App Service minska komplexiteten, medan AKS ger mer flexibilitet och kontroll. Mer experimentella appmodeller som OSS Radius-inkubationsprojektet försöker ge en balans mellan de två, men är vanligtvis i tidigare mognadsstadier än molntjänster med fullt stöd och närvaro i etablerade IaC-format.

De problem som du identifierade när du planerade bör hjälpa dig att utvärdera vilket slut på den här skalan som passar dig. Tänk på att ta med dina egna interna kunskaper i beslutsprocessen.

Delade kontra dedikerade resurser

I din egendom finns det många resurser som kan delas av flera program för att öka användningen och kostnadseffektiviteten. Var och en av de resurser som kan delas har en egen uppsättning överväganden. Det här är till exempel överväganden för att dela K8-kluster, men vissa gäller för andra typer av resurser:

  • Organisation: Genom att dela resurser som kluster inom, i stället för över, kan organisationens gränser förbättra hur de överensstämmer med organisationens riktning, krav, prioritet osv.
  • Programinnehavare: Program kan ha olika krav på innehavarisolering. Du måste granska enskilda programsäkerhet och regelefterlevnad om de kan samexistera med andra program. 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 metod nyckeln till att undvika förvirring och misstag.
  • Resursförbrukning: Förstå varje programresursanvändning, outnyttjad kapacitet och gör en prognos för att uppskatta om delning är lönsamt. Du bör också vara medveten om gränserna för de resurser som används (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 live-platsincidenter på grund av kapacitetsöverbelastning. Genom att använda resursgränser, representativ testning, övervakningsaviseringar och rapportering kan du identifiera resursförbrukning och skydda mot program som förbrukar för många resurser som kan påverka andra program.
  • Optimera delade konfigurationer: Delade resurser, till exempel delade kluster, kräver extra överväganden och konfiguration. Dessa överväganden omfattar korsladdning, resursallokering, behörighetshantering, arbetsbelastningsägarskap, datadelning, uppgraderingssamordning, arbetsbelastningsplacering, etablering, hantering och iterering av en baslinjekonfiguration, kapacitetshantering och placering av arbetsbelastningar. Delade resurser har fördelar, men om standardkonfigurationerna är för restriktiva och inte utvecklas blir de föråldrade.

Vissa av dessa problem förenklas av PaaS-lösningar, men många av dessa punkter gäller även för något som en delning av en databas. Delning har både ups-sides och down-side och så du bör överväga kompromisserna noggrant.

Mer information om Kubernetes-klusteraspekten i den här artikeln finns i dokumentationen om Azure Kubernetes Service (AKS) för flera innehavare.

Styrelseformer

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. Styrning är ett brett ämne, men om det här är ett problem som du stöter på bör du tänka på båda aspekterna av det här utrymmet:

  • Inledande distributionsefterlevnad (starta till 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 K8 tillsammans med operativsystem 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 (till exempel Azure).

För att upprätthålla efterlevnaden krävs verktyg för att komma åt, rapportera och agera på problem. Till exempel kan Azure Policy 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å avbryta program oväntat. Överväg därför att utveckla till en princip som kod (PaC) när du arbetar i stor skala. Som en viktig del av din starträtt och håll dig till rätt metod tillhandahåller PaC:

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

PaC kan bidra till att minimera explosionsradien för potentiellt en felaktig princip 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 & reparation av befintliga resurser bidrar till att minimera explosionsradien för potentiellt en felaktig princip.
  • Reparationsuppgiften har inbyggd säkerhet, med kontroller som att stoppa reparationsaktiviteten om mer än 90 procent av distributionerna misslyckas.

Observerbarhet

För att stödja dina program och din infrastruktur behöver du observerbarhet och loggning i hela stacken som dina plattformstekniker, drifts- och utvecklarteam kan använda för att se vad som händer.

Bild av en Grafana-instrumentpanel.

Kraven varierar dock per roll. Plattformsteknik- och driftteamet kräver till exempel instrumentpaneler för att granska infrastrukturens hälsa och kapacitet med lämpliga aviseringar. Utvecklare behö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: Tillämpa loggningsstandarder för att göra det enklare att skapa och återanvända standardiserade instrumentpaneler och förenkla inmatningsbearbetningen via något som liknar OpenTelemetry-ramverket för observerbarhet.
  • Behörigheter: Överväg att tillhandahålla instrumentpaneler på team- eller programnivå med något som Grafana för att tillhandahålla samlade data för alla som är intresserade, tillsammans med en funktion för betrodda medlemmar i programteam för 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 kvarhållningsstandarder och publicera dem som en del av vägledningen för starträtt.
  • Övervaka resursgränser: Driftteamen bör kunna identifiera och spåra eventuella begränsningar för en viss typ av resurs. När det är möjligt bör dessa begränsningar räknas in i IaC-mallar eller principer med hjälp av verktyg som Azure Policy. Åtgärder bör sedan proaktivt övervaka användning av instrumentpaneler i något som Grafana och expandera delade resurser där automatiserad skalning inte är möjlig eller aktiverad. Övervaka till exempel antalet K8-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 (exempel: CPU, minne, lagring) för svält med måttsamling med något som Prometheus eller Azure Container Insights. Du kan övervaka socketar/portar som används, nätverksbandbreddsförbrukning för chattiga appar och antalet tillståndskänsliga program i klustret.

Säkerhet

Säkerhet krävs på varje lager, från kod, container, kluster och moln/infrastruktur. Varje organisation har sina egna säkerhetskrav, men på hög nivå är det här några saker att tänka på för din plattform:

  • Följ principen om lägsta behörighet.
  • Förena din DevOps-säkerhetshantering över flera pipelines.
  • Se till att sammanhangsbaserade insikter för att identifiera och åtgärda din mest kritiska risk visas.
  • Aktivera identifiering och svar på moderna hot i dina molnarbetsbelastningar vid körning.

För att lösa problem i 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 vill du utvärdera:

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

Det kan vara svårt att hantera identitetsåtkomst till tjänster, program och infrastruktur i stor skala. Du vill att identitetsprovidrar ska kunna skapa, underhålla och hantera identitetsinformation samtidigt som du tillhandahåller autentiseringstjänster till program och tjänster och som kan integreras med rollbaserade åtkomstkontrollauktoriseringssystem för skalningsbaserad autentisering och auktoriseringshantering (RBAC). Du kan till exempel använda Azure RBAC och 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å det säkraste möjliga sättet. I AKS kan till exempel molnbaserade appar använda en arbetsbelastningsidentitet som federeras med Microsoft Entra ID så att containerbaserade arbetsbelastningar kan autentiseras. Den här metoden gör att program kan komma åt molnresurser utan hemliga utbyten i programkod.

Metadata & kostnadshantering

Kostnaden är ett annat problem som kan bubbla upp till toppen för dina plattformstekniska insatser. För att kunna hantera programplattformen korrekt behöver du ett sätt att identifiera arbetsbelastningsägare. Du vill ha ett sätt att få en inventering av resurser som mappar 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 metadata innehålla obligatoriska egenskaper (med något som Azure Policy) när du distribuerar arbetsbelastningar och resurser. Detta hjälper till med kostnadstilldelning, resursmappning av lösningar, ägare osv. Ö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, till exempel din identitetsprovider, loggning & måttlagring och bandbreddsförbrukning för nätverk. För delade resurser kan du dela upp driftskostnaderna för de enskilda teamen lika eller tillhandahålla dedikerade system (till exempel loggningslagring) där det finns en icke-enhetlig förbrukning. Vissa delade resurstyper kanske kan ge insikter om resursförbrukning, till exempel har Kubernetes verktyg som OpenCost eller Kubecost och kan hjälpa till.

Du bör också leta efter verktyg för kostnadsanalys där du kan granska aktuella utgifter. I Azure Portal 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.

Utforma en självbetjäningsgrund för utvecklare