Delen via

Uw toepassingsplatform verfijnen

  • Artikel

Zodra u de problemen begrijpt die u als eerste wilt aanpakken in uw platform-engineeringtraject, zult u mogelijk een aantal uitdagingen met uw toepassingsplatform moeten aanpakken. In dit artikel vindt u enkele tips voor hoe u dat kunt doen. U leert meer over de vaak gemiste of vergeten aspecten van het maken van een goed ontworpen toepassingsplatform. Met name infrastructuurbeheer, beveiliging, kostenbeheer, governance en waarneembaarheid.

Bepalen wanneer en waar u wilt investeren

Als u momenteel een of meer toepassingsplatformen hebt, kan het lastig zijn om te bepalen wanneer en waar u wilt investeren in verbeteringen waarmee de problemen die u hebt geïdentificeerd, worden opgelost. Als u opnieuw begint, heeft het Azure Architecture Center verschillende mogelijke patronen die u kunt evalueren. Maar verder zijn hier enkele vragen die u moet overwegen wanneer u begint met het plannen van wat u wilt doen:

Vraag Tips
Wilt u uw bestaande toepassingsplatform aanpassen, een nieuwe start maken of een combinatie van deze benaderingen gebruiken? Zelfs als u tevreden bent met wat u nu hebt of als u nieuw begint, moet u nadenken over hoe u zich in de loop van de tijd kunt aanpassen aan veranderingen. Snel knippen werkt zelden. Hoe dan ook, net als technische systemen, zijn uw toepassingsplatforms een bewegend doel. Waar je vandaag op terechtkomt, verandert naarmate de tijd verstrijkt. U moet deze gedachte en eventuele gerelateerde migratieplannen mee in uw ontwerp voor de toekomst. Meer informatie over al behandelde infrastructure as code (IaC) en tijdelijke benaderingen vindt u in Software engineering-systemen toepassen om u te helpen een deel van deze variatie voor nieuwe toepassingen te beheren.
Als u wilt veranderen wat u vandaag doet, met welke producten, services of investeringen bent u tevreden? Zoals het gezegde luidt, "als het niet gebroken is, los het dan niet op." Wijzig dingen niet zonder een reden om dit te doen. Als u echter zelf oplossingen hebt, kunt u overwegen of het tijd is om over te stappen op een bestaand product om te besparen op onderhoud op lange termijn. Als u bijvoorbeeld uw eigen bewakingsoplossing gebruikt, wilt u die last van uw ops-team verwijderen en migreren naar een nieuw beheerd product?
Waar ziet u de meeste veranderingen in de loop van de tijd? Bevinden deze zich in gebieden die gemeenschappelijk zijn voor alle (of de meeste) app-typen van uw organisatie? Gebieden waar u of uw interne klanten niet tevreden mee zijn en die waarschijnlijk niet vaak veranderen, zijn goede plaatsen om te beginnen. Deze hebben het grootste rendement op investeringen op de lange termijn. Dit kan u ook helpen bij het vergemakkelijken van de migratie naar een nieuwe oplossing. App-modellen zijn bijvoorbeeld vaak vloeiend, maar hulpprogramma's voor logboekanalyse hebben vaak een langere houdbaarheid. U kunt zich ook richten op nieuwe projecten/toepassingen om te starten terwijl u bevestigt dat de richtingswijziging de gewenste resultaten heeft.
Investeert u in aangepaste oplossingen op gebieden met de hoogste toegevoegde waarde? Bent u sterk van mening dat een unieke app-infrastructuurplatformfunctie deel uitmaakt van uw concurrentievoordeel? Als u hiaten hebt geïdentificeerd voordat u iets op maat gaat doen, moet u overwegen in welke gebieden leveranciers waarschijnlijk zullen investeren en uw aangepaste denkwijze elders zullen richten. Begin met uzelf te zien als een integrator in plaats van een aangepaste app-infrastructuur of app-modelprovider. Alles wat u bouwt, moet worden onderhouden, wat op de lange termijn de kosten op de voorgrond kost. Als u denkt dat het dringend nodig is om een aangepaste oplossing te bouwen in een gebied dat waarschijnlijk op lange termijn wordt gedekt door leveranciers, kunt u ondersteuning op lange termijn plannen voor ondersteuning of ondersteuning op lange termijn. Uw interne klanten zijn doorgaans net zo blij (zo niet meer) met een kant-en-klare product als een aangepast product.

Het aanpassen van uw bestaande investeringen in het toepassingsplatform kan een goede manier zijn om aan de slag te gaan. Wanneer u updates aanbrengt, kunt u overwegen om te beginnen met nieuwe toepassingen om testideeën te vereenvoudigen vóór elke vorm van implementatie. Houd rekening met deze wijziging via IaC en toepassings templating. Investeer in aangepaste oplossingen voor uw unieke behoeften op gebieden met een hoge impact en hoge waarde. Probeer anders een standaardoplossing te gebruiken. Net als bij technische systemen richt u zich op het automatiseren van inrichting, tracering en implementatie in plaats van uit te gaan van één strikt pad om u te helpen bij het beheren van wijzigingen in de loop van de tijd.

Ontwerp- en architectuuroverwegingen

Hoewel er verschillende mogelijke toepassingsplatformpatronen zijn die u kunt gebruiken, zijn hier enkele veelvoorkomende gebieden die essentieel zijn, maar vaak worden gemist tijdens het ontwerp.

Infrastructuurbeheer

Zoals vermeld in Software Engineering-systemen toepassen, kunnen IaC- en automatiseringsprogramma's worden gecombineerd met sjablonen om de infrastructuur en toepassingsimplementatie te standaardiseren. Als u de last van platformspecifieke gegevens voor de eindgebruiker wilt verminderen, moet u platformdetails abstraheren door keuzes op te delen in herkenbare naamconventies, bijvoorbeeld:

  • Resourcetypecategorieën (hoog rekenproces, hoog geheugen)
  • Resourcegroottecategorieën (grootte van t-shirt, klein normaal en groot.)

Het doel moet zijn om sjablonen te hebben die algemene vereisten vertegenwoordigen die zijn getest met vooraf ingestelde configuraties, zodat ontwikkelteams onmiddellijk aan de slag kunnen met het leveren van minimale parameters en zonder opties te hoeven controleren. Het kan echter gebeuren dat teams meer opties voor gepubliceerde sjablonen moeten wijzigen dan beschikbaar of wenselijk is. Een goedgekeurd ontwerp heeft bijvoorbeeld mogelijk een specifieke configuratie nodig die buiten de ondersteunde sjabloon standaardinstellingen valt. In dit geval kunnen bewerkings- of platformengineeringsteams een eenmalige configuratie maken en vervolgens beslissen of de sjabloon deze wijzigingen als standaard moet opnemen.

U kunt wijzigingen bijhouden met behulp van IaC-hulpprogramma's met functies voor afwijkingsdetectie waarmee drift automatisch kan worden hersteld (GitOps). Voorbeelden van deze hulpprogramma's zijn Terraform en cloudeigen IaC-hulpprogramma's (voorbeelden, Cluster-API, Crossplane, Azure Service Operator v2). Buiten IaC-hulpprogrammadrift detecteren er cloudconfiguratiehulpprogramma's die query's kunnen uitvoeren op resourceconfiguraties, zoals Azure Resource Graph. Deze kunnen als twee voordelen dienen; controleert u op wijzigingen buiten de infrastructuurcode en controleert u op gewijzigde vooraf ingestelde configuraties. Als u wilt voorkomen dat u te star bent, kunt u toleranties ook implementeren in implementaties met vooraf gedefinieerde limieten. U kunt bijvoorbeeld Azure Policy gebruiken om het aantal Kubernetes-knooppunten te beperken dat een implementatie kan hebben.

Zelfbeheerd of beheerd?

In openbare clouds hebt u de keuze om SaaS, PaaS of IaaS te gebruiken. Zie de trainingsmodule Cloudconcepten beschrijven voor meer informatie over SaaS, PaaS en IaaS. PaaS-services bieden gestroomlijnde ontwikkelervaringen, maar zijn meer prescriptief met hun app-modellen. Uiteindelijk is er een afweging tussen gebruiksgemak en controle die u moet evalueren.

Evalueer en geef prioriteit aan de services die u wilt aanbieden of verplaatsen tijdens het ontwerpen van het platform. Of u apps bijvoorbeeld rechtstreeks op Azure Kubernetes Service (AKS) of via Azure Container Apps (ACA) bouwt, is afhankelijk van uw vereisten voor de service en van uw interne capaciteit en vaardighedenset. Hetzelfde geldt voor functies zoals Azure Functions of Azure App Service. ACA, Azure Functions en App Service de complexiteit verminderen, terwijl AKS meer flexibiliteit en controle biedt. Meer experimentele app-modellen zoals het OSS Radius-incubatieproject proberen een balans tussen de twee te bieden, maar bevinden zich over het algemeen in een eerder stadium van volwassenheid dan cloudservices met volledige ondersteuning en aanwezigheid in gevestigde IaC-indelingen.

De problemen die u tijdens het plannen hebt geïdentificeerd, moeten u helpen te evalueren welk einde van deze schaal voor u geschikt is. Zorg ervoor dat u rekening moet houden met uw eigen interne bestaande vaardighedensets wanneer u een beslissing neemt.

Gedeelde versus toegewezen resources

Binnen uw domein zijn er veel resources die kunnen worden gedeeld door meerdere toepassingen om het gebruik en de kosteneffectiviteit te verhogen. Elk van de resources die kunnen worden gedeeld, heeft een eigen set overwegingen. Dit zijn bijvoorbeeld overwegingen voor het delen van K8s-clusters, maar sommige zijn van toepassing op andere typen resources:

  • Organisatie: Het delen van resources zoals clusters binnen, in plaats van over organisatiegrenzen heen, kan de afstemming op de richting, vereisten, prioriteit, enzovoort van de organisatie verbeteren.
  • Toepassingstenancy: Toepassingen kunnen verschillende tenancy-isolatievereisten hebben; u moet de afzonderlijke toepassingsbeveiliging en naleving van regelgeving controleren als deze naast andere toepassingen kan bestaan. In Kubernetes kunnen toepassingen bijvoorbeeld naamruimteisolatie gebruiken. Maar u moet ook rekening houden met toepassingstenancy voor verschillende omgevingstypen. Het is bijvoorbeeld vaak het beste om te voorkomen dat testtoepassingen worden gemengd met productietoepassingen op dezelfde clusters om onverwachte gevolgen als gevolg van onjuiste configuraties of beveiligingsproblemen te voorkomen. U kunt er ook voor kiezen om eerst toegewezen Kubernetes-clusters te testen en af te stemmen om deze problemen op te sporen vóór de implementatie op een gedeeld cluster. Hoe dan ook, consistentie in uw aanpak is de sleutel om verwarring en fouten te voorkomen.
  • Resourceverbruik: Krijg inzicht in het gebruik van elke toepassingsresource en reservecapaciteit en maak een projectie om in te schatten of delen haalbaar is. U moet ook rekening houden met de limieten van de verbruikte resources (datacentrumcapaciteit of abonnementslimieten). Het doel is om te voorkomen dat uw toepassing en afhankelijkheden worden verplaatst vanwege resourcebeperkingen in een gedeelde omgeving of dat er live site-incidenten zijn vanwege capaciteitsuitputting. Het gebruik van resourcelimieten, representatieve tests, bewaking van waarschuwingen en rapportage kunnen helpen bij het identificeren van resourceverbruik en bescherming tegen toepassingen die te veel resources verbruiken die van invloed kunnen zijn op andere toepassingen.
  • Gedeelde configuraties optimaliseren: Gedeelde resources, zoals gedeelde clusters, vereisen extra aandacht en configuratie. Deze overwegingen omvatten kruislingse kosten, resourcetoewijzing, machtigingenbeheer, eigendom van workloads, het delen van gegevens, upgrade-coördinatie, plaatsing van workloads, het opzetten, beheren en herhalen van een basislijnconfiguratie, capaciteitsbeheer en plaatsing van workloads. Gedeelde resources hebben voordelen, maar als de standaardconfiguraties te beperkend zijn en zich niet ontwikkelen, worden ze verouderd.

Sommige van deze problemen worden vereenvoudigd door PaaS-oplossingen, maar veel van deze punten zijn zelfs van toepassing op iets als het delen van een database. Delen heeft zowel aan- als zijkanten en down-sides en daarom moet u de afwegingen zorgvuldig overwegen.

Zie de documentatie over meerdere Azure Kubernetes Service tenants (AKS) voor meer informatie over het kubernetes-clusteraspect van dit artikel.

Governance

Governance is een belangrijk onderdeel van het inschakelen van selfservice met kaders, maar het toepassen van nalevingsregels op een manier die geen invloed heeft op de time-to-business-waarde voor toepassingen is een veelvoorkomende uitdaging. Governance is een breed onderwerp, maar als dit een probleem is dat u ondervindt, houd dan rekening met beide aspecten van deze ruimte:

  • Initiële implementatienaleving (begin rechts): Dit kan worden bereikt met gestandaardiseerde IaC-sjablonen die beschikbaar worden gesteld via catalogi, met machtigingsbeheer en beleid om ervoor te zorgen dat alleen toegestane resources en configuraties kunnen worden geïmplementeerd.
  • Naleving handhaven (rechts blijven): Hulpprogramma's op basis van beleid kunnen voorkomen of u waarschuwen wanneer er resourcewijzigingen zijn. Naast uw kerninfrastructuur ondersteunen hulpprogramma's ook naleving binnen resources zoals K8's, samen met besturingssystemen die worden gebruikt in uw containers of VM's. U kunt bijvoorbeeld een vergrendelde besturingssysteemconfiguratie afdwingen of hulpprogramma's voor beveiligingssoftware installeren, zoals Windows groepsbeleid, SELinux, AppArmor, Azure Policy of Kyverno. Als ontwikkelaars alleen toegang hebben tot IaC-opslagplaatsen, kunt u goedkeuringswerkstromen toevoegen om voorgestelde wijzigingen te controleren en directe toegang tot resourcebeheervlakken (bijvoorbeeld Azure) te voorkomen.

Voor het handhaven van de naleving zijn hulpprogramma's vereist om problemen te openen, te rapporteren en erop te reageren. Azure Policy kan bijvoorbeeld worden gebruikt met veel Azure-services voor controle, rapportage en herstel. Het heeft ook verschillende modi, zoals Audit, Deny en DeployIfNotExists, afhankelijk van uw behoeften.

Hoewel beleidsregels naleving kunnen afdwingen, kunnen ze ook toepassingen onverwacht onderbreken. Overweeg daarom om te evolueren naar een beleid als code (PaC) wanneer u op schaal werkt. Als een belangrijk onderdeel van uw aanpak voor het juiste begin en behoud rechts , biedt PaC het volgende:

  • Centraal beheerde standaarden
  • Versiebeheer voor uw beleid
  • Automatische validatie van testen &
  • Kortere implementatietijd
  • Continue implementatie

PaC kan helpen om de straal van een mogelijk slecht beleid te minimaliseren met mogelijkheden zoals:

  • Beleidsdefinities die zijn opgeslagen als code in een opslagplaats die wordt gecontroleerd en goedgekeurd.
  • Automatisering voor testen en validatie.
  • Op ring gebaseerde geleidelijke implementatie van beleidsregels & herstel op bestaande resources helpen de straal van mogelijk slecht beleid te minimaliseren.
  • Hersteltaak heeft ingebouwde beveiliging, met besturingselementen zoals het stoppen van de hersteltaak als meer dan 90 procent van de implementaties mislukken.

Observability

Ter ondersteuning van uw toepassingen en infrastructuur hebt u waarneembaarheid en logboekregistratie nodig voor de hele stack die uw platform engineering-, operations- en ontwikkelaarsteams kunnen gebruiken om te zien wat er gebeurt.

Afbeelding van een Grafana-dashboard.

De vereisten verschillen echter per rol. Het platformengineerings- en operations-team vereist bijvoorbeeld dashboards om de status en capaciteit van de infrastructuur te controleren met geschikte waarschuwingen. Ontwikkelaars hebben metrische gegevens, logboeken en traceringen van toepassingen nodig voor het oplossen van problemen en aangepaste dashboards die de status van de toepassing en infrastructuur weergeven. Een probleem dat een van deze rollen kan tegenkomen, is cognitieve overbelasting door te veel informatie of kennislacunes vanwege een gebrek aan nuttige informatie.

Houd rekening met het volgende om deze uitdagingen op te lossen:

  • Normen: Pas logboekregistratiestandaarden toe om het eenvoudiger te maken en te hergebruiken gestandaardiseerde dashboards en om opnameverwerking te vereenvoudigen via zoiets als het OpenTelemetry-framework voor waarneembaarheid.
  • Machtigingen: Overweeg dashboards op team- of toepassingsniveau te bieden met behulp van iets als Grafana om samengetelde gegevens te bieden voor iedereen die geïnteresseerd is, samen met een faciliteit voor vertrouwde leden van toepassingsteams om veilig toegang te krijgen tot logboeken wanneer dat nodig is.
  • Retentie: Het bewaren van logboeken en metrische gegevens kan duur zijn en kan onbedoelde risico's of schendingen van de naleving met zich meebrengen. Stel standaardinstellingen voor retentie in en publiceer deze als onderdeel van de richtlijnen voor de juiste start.
  • Resourcelimieten bewaken: Operations-teams moeten beperkingen voor een bepaald type resource kunnen identificeren en volgen. Indien mogelijk moeten deze beperkingen worden meegenomen in IaC-sjablonen of -beleid met behulp van hulpprogramma's zoals Azure Policy. Bewerkingen moeten vervolgens proactief worden bewaakt met behulp van dashboards in iets als Grafana en gedeelde resources uitbreiden waar geautomatiseerd schalen niet mogelijk of ingeschakeld is. Bewaak bijvoorbeeld het aantal K8s-clusterknooppunten voor capaciteit wanneer apps worden onboarden en in de loop van de tijd worden gewijzigd. Waarschuwingen zijn nodig en deze definities moeten worden opgeslagen als code, zodat ze programmatisch kunnen worden toegevoegd aan resources.
  • Belangrijke metrische gegevens over capaciteit en status identificeren: Besturingssysteem en gedeelde resources (voorbeelden: CPU, geheugen, opslag) bewaken en waarschuwen voor uitsterking met verzameling van metrische gegevens met behulp van iets als Prometheus of Azure Container Insights. U kunt sockets/poorten die worden gebruikt, het gebruik van netwerkbandbreedte van spraakmakende apps en het aantal stateful toepassingen dat op het cluster wordt gehost, bewaken.

Veiligheid

Beveiliging is vereist op elke laag, van code, container, cluster en cloud/infrastructuur. Elke organisatie heeft zijn eigen beveiligingsvereisten, maar op hoog niveau zijn dit enkele dingen die u moet overwegen voor uw platform:

  • Volg het principe van minimale bevoegdheden.
  • Uw DevOps-beveiligingsbeheer voor meerdere pijplijnen samenvoegen.
  • Zorg ervoor dat contextuele inzichten voor het identificeren en oplossen van uw meest kritieke risico zichtbaar zijn.
  • Schakel detectie en reactie op moderne bedreigingen in uw cloudworkloads in tijdens runtime.

Om problemen op dit gebied op te lossen, hebt u hulpprogramma's nodig om hulpprogramma's te evalueren die werken in uw engineering- en toepassingssystemen, resources en services in clouds en hybride (bijvoorbeeld Microsoft Defender voor cloud). Naast toepassingsbeveiliging moet u het volgende evalueren:

Machtigingsvereisten kunnen per omgeving verschillen. In sommige organisaties hebben afzonderlijke teams bijvoorbeeld geen toegang tot productieresources en kunnen nieuwe toepassingen pas automatisch worden geïmplementeerd als de beoordelingen zijn voltooid. In ontwikkel- en testomgevingen kunnen geautomatiseerde resource- en app-implementatie en toegang tot clusters voor probleemoplossing echter zijn toegestaan.

Het beheren van identiteitstoegang tot services, toepassingen en infrastructuur op schaal kan lastig zijn. U wilt dat id-providers identiteitsgegevens maken, onderhouden en beheren terwijl ze verificatieservices leveren aan toepassingen en services en die kunnen worden geïntegreerd met autorisatiesystemen voor op rollen gebaseerd toegangsbeheer voor verificatie en autorisatiebeheer op schaal (RBAC). U kunt bijvoorbeeld Azure RBAC en Microsoft Entra ID gebruiken om verificatie en autorisatie op schaal te bieden voor Azure-services zoals Azure Kubernetes Service zonder dat u machtigingen rechtstreeks op elk afzonderlijk cluster hoeft in te stellen.

Toepassingen hebben mogelijk toegang nodig tot een identiteit om toegang te krijgen tot cloudresources zoals opslag. U moet de vereisten bekijken en beoordelen hoe uw id-provider dit op de veiligste manier kan ondersteunen. In AKS kunnen cloudeigen apps bijvoorbeeld gebruikmaken van een workloadidentiteit die federeert met Microsoft Entra ID om in containers geplaatste workloads te kunnen verifiëren. Met deze benadering kunnen toepassingen toegang krijgen tot cloudresources zonder geheime uitwisseling binnen toepassingscode.

Metagegevens & kostenbeheer

Kosten zijn een ander probleem dat naar de top kan gaan voor uw platform engineering-inspanningen. Als u uw toepassingsplatform goed wilt beheren, hebt u een manier nodig om eigenaren van workloads te identificeren. U wilt een manier om een inventaris van resources op te halen die wordt toegewezen aan eigenaren voor een bepaalde set metagegevens. In Azure kunt u bijvoorbeeld AKS-labels, Azure Resource Manager-tags gebruiken, samen met concepten zoals projecten in Azure-implementatieomgevingen om uw resources op verschillende niveaus te groepeert. Dit werkt alleen als de gekozen metagegevens verplichte eigenschappen bevatten (met iets als Azure Policy) bij het implementeren van workloads en resources. Dit helpt bij kostentoewijzing, toewijzing van oplossingsresources, eigenaren, enzovoort. Overweeg om regelmatige rapportage uit te voeren om zwevende resources bij te houden.

Naast het bijhouden, moet u mogelijk kosten toewijzen aan afzonderlijke toepassingsteams voor hun resourcegebruik met behulp van dezelfde metagegevens met kostenbeheersystemen zoals Microsoft Cost Management. Hoewel deze methode resources bijhoudt die zijn ingericht door de toepassingsteams, worden de kosten van gedeelde resources zoals uw id-provider, logboekregistratie & opslag met metrische gegevens en netwerkbandbreedteverbruik niet meegeteld. Voor gedeelde resources kunt u de operationele kosten evenredig verdelen over de afzonderlijke teams of speciale systemen (bijvoorbeeld opslag voor logboekregistratie) bieden wanneer er sprake is van niet-uniform verbruik. Sommige gedeelde resourcetypen kunnen mogelijk inzicht geven in het resourceverbruik. Kubernetes heeft bijvoorbeeld hulpprogramma's zoals OpenCost of Kubecost en kan hierbij helpen.

U moet ook zoeken naar hulpprogramma's voor kostenanalyse, waar u de huidige uitgaven kunt bekijken. In Azure Portal zijn er bijvoorbeeld kostenwaarschuwingen en budgetwaarschuwingen waarmee het verbruik van resources in een groep kan worden bijgehouden en meldingen kunnen worden verzonden wanneer u vooraf ingestelde drempelwaarden bereikt.

Een selfservicebasis voor ontwikkelaars ontwerpen