Mange virksomheder er gået fra at have et enkelt dominerende operativsystem til at sameksistere med Windows-servere, Linux, fysiske maskiner, offentlige clouds og lokale miljøer , der skal kommunikere problemfrit uden at forstyrre noget. Spørgsmålet er ikke længere, om et hybridt arbejdsområde er muligt, men hvordan man organiserer disse arbejdsgange for at sikre, at de er sikre, gentagelige og nemme at vedligeholde.
Når du blander Windows og Linux sammen med flere cloud-løsninger, har du brug for mere end bare gode scripts. Du har brug for en klar strategi for at skabe hybride Windows-Linux-arbejdsgange , der integrerer automatisering, orkestrering, sikkerhed og overvågning ved hjælp af de rigtige elementer: Azure Automation og Hybrid Runbook Worker, Logic Apps i hybridtilstand, Ansible, AWS Systems Manager, desktopværktøjer som WinApps og hele det moderne udviklings- og samarbejdslag i Microsoft 365 og Windows.
Hvorfor er hybride Windows-Linux-arbejdsgange ikke længere valgfrie?
I de fleste organisationer i dag kører Linux-maskiner kritiske applikationer sideløbende med Windows-servere, der kører interne tjenester, databaser og ældre applikationer . Vedligeholdelse af to isolerede miljøer, hver med sine egne værktøjer, fører til dobbeltarbejde og en dramatisk stigning i menneskelige fejl.
Når du begynder at administrere snesevis eller hundredvis af blandede servere , bliver manuelle procedurer og separate scripts upraktiske. Du har brug for et automatiserings- og orkestreringslag, der giver dig mulighed for at definere processer én gang og køre dem, hvor det er nødvendigt, uanset om det er på Windows, Linux, i skyen eller i dit datacenter.
I denne sammenhæng dukker flere nøgleelementer op: Azure Automation med Hybrid Runbook Worker til at bringe automatisering til dit netværk, Logic Apps i hybridtilstand til at integrere distribuerede systemer , Ansible som et fælles sprog mellem Linux og Windows, AWS Systems Manager til hybridnoder og værktøjer som WinApps, der giver dig mulighed for at bruge Windows-applikationer fra Linux-desktops uden problemer.
Hybridautomatisering med Azure Automation og Hybrid Runbook Worker
Et vigtigt første skridt i oprettelsen af hybride arbejdsgange er at implementere Azure Automation-runbooks på dine lokale Windows- og Linux-servere eller servere i andre clouds . Det er her, Hybrid Runbook Worker-funktionen kommer ind i billedet, så du kan køre runbooks direkte på de maskiner, der hoster denne rolle.
Runbooks forbliver gemt og administreret i Azure Automation , men leveres til en eller flere maskiner, der er registreret som Hybrid Runbook Workers. Dette giver dig mulighed for at automatisere lokale eller cloud-ressourcer uden at eksponere dem direkte til internettet eller skulle omskrive hele din automatisering uden for Azure.
Udvidelser vs. klassisk agent: To måder at installere Hybrid Runbook Worker på
I dag kan du implementere Hybrid Runbook Worker-brugerrollen ved hjælp af to forskellige installationsplatforme: udvidelsesbaseret og agentbaseret . Efter installationen er runbook-udførelsesadfærden den samme, men den udvidelsesbaserede tilgang forenkler onboarding og vedligeholdelse radikalt.
Den traditionelle tilgang var baseret på Log Analytics-agenten , hvilket resulterede i en længere og mere fejlbehæftet proces. Den udvidelsesbaserede model integreres nativt med Azure Virtual Machine Extensions Framework ved hjælp af Azure VM-agenten til Azure VM'er og Azure Connected Machine-agenten til ikke-Azure-maskiner, herunder Azure Arc-aktiverede servere og Arc-aktiverede VMware vSphere.
Begge typer Hybrid Runbook Worker kan sameksistere på den samme maskine , og den udvidelsesbaserede installation forstyrrer ikke instanser, du allerede har installeret ved hjælp af den traditionelle agent, hvilket muliggør problemfri, trinvise migreringer.
Vigtigste fordele ved den udvidelsesbaserede tilgang
Den udvidelsesbaserede model reducerer operationel friktion betydeligt ved implementering af en brugers Hybrid Runbook Worker ved at eliminere unødvendige afhængigheder. De vigtigste fordele inkluderer:
- Meget mere gnidningsfri onboardingDu er ikke længere afhængig af Log Analytics-agenten til at registrere arbejdere, hvilket undgår flertrinsprocesser og almindelige fejl i manuelle installationer.
- Centraliseret styring skalerer alleredeDirekte integration med Azure Resource Manager (ARM)-identitet, der muliggør styring af storstilet implementering ved hjælp af politikker, ARM-skabeloner, Bicep, PowerShell eller CLI.
- Godkendelse med Microsoft-logon-IDSystemtildelte administrerede identiteter udnyttes på virtuelle maskiner, således at Legitimationsoplysninger administreres på en samlet måde og uden at gemme dem i almindelig tekst i scripts eller konfigurationer.
- Samme model for Azure og Azure ArcBåde maskiner i Azure og fysiske servere eller VM'er hos andre udbydere (via Azure Arc) administreres. med den samme oplevelseDette forenkler hybrid- og multicloud-miljøer i høj grad.
- Flere adgangsvejeRollen kan installeres fra Azure Portal, PowerShell, Bicep, ARM-skabeloner, Azure REST eller CLI, eller direkte fra fanen i Udvidelser af hver Arc-aktiveret virtuel maskine eller server.
- Automatiske opdateringer af mindre versionerSom standard opdaterer udvidelsesbaserede Workers automatisk til nye mindre versioner, hvilket reducerer vedligeholdelsesbyrden ved at holde sig opdateret. sikkerhedsrettelser og forbedringerHovedversionerne kræver dog stadig manuelle opdateringer.
Begrænsninger og organisering af Hybrid Runbook Workers
Med hensyn til kapacitet tillader hver Automation-konto op til 4000 system-Hybrid Runbook-arbejdere og 4000 bruger-Hybrid Runbook-arbejdere . Hvis du har brug for at administrere mere end 4000 maskiner, anbefales det at oprette en ny Automation-konto for at fordele arbejdsbyrden.
Hver brugers Hybrid Runbook Worker tilhører en Worker-gruppe , som du definerer under installationen. En gruppe kan være vært for en enkelt instans eller flere instanser for at opnå høj tilgængelighed. En enkelt maskine kan kun sende heartbeats til én Automation-konto ; det vil sige, at den ikke kan registreres som en Worker i flere konti samtidigt.
Grupperne er designet til at tilbyde høj tilgængelighed og belastningsbalancering ved at fordele job blandt deres medlemmer. Arbejderne bruger en afstemningsmekanisme: hver aktiv arbejder forespørger tjenesten hvert 30. sekund og kan indsamle op til 4 job pr. "ping". Hvis antallet af jobmodtagelser overstiger arbejdernes samlede kapacitet, kan nogle blive suspenderet med en fejl.
Hvis ingen arbejdere i en gruppe har pinget tjenesten i de sidste 30 minutter, anser Azure gruppen for at have ingen aktive arbejdere . I så fald forsøges jobs at blive gentaget tre gange og derefter suspenderet. Denne funktionsmåde er nøglen til korrekt dimensionering af antallet af arbejdere baseret på den forventede arbejdsbyrde.
Funktioner og udførelsesgrænser i Hybrid Runbook Worker
En vigtig detalje er, at en Hybrid Runbook Worker-instans ikke er begrænset af Azure-sandbox-grænser med hensyn til disk, hukommelse eller netværkssockets. De reelle begrænsninger skyldes selve serverens fysiske ressourcer, hvilket er afgørende for at køre langvarige eller meget intensive automatiseringer.
Hvis værtscomputeren for en Hybrid Runbook Worker genstarter, mens en runbook kører, genstartes jobbet fra begyndelsen eller fra det sidste kontrolpunkt i tilfælde af PowerShell Workflow-runbooks. Hvis det samme job genstartes mere end tre gange, suspenderes det for at forhindre uendelige løkker.
På Windows kører job under den lokale systemkonto , og på Linux under nxautomation- kontoen . Da disse runbooks ofte tilgår ressourcer uden for Azure, kan de ikke udelukkende stole på den typiske Azure runbook-godkendelsesmekanisme; de kræver lokal ressourcespecifik godkendelse eller brug af korrekt konfigurerede administrerede identiteter og udførelseskonti.
For bedre at organisere arbejdsgange kan du registrere den samme maskine i flere Hybrid Runbook Worker-grupper inden for den samme konto og dirigere forskellige runbooks til hver gruppe baseret på arbejdsbelastningstype, tidsplaner eller kritiske forhold.
Typiske scenarier med Hybrid Runbook Worker
De mest almindelige anvendelsesscenarier for Hybrid Runbook Worker kombinerer Windows- og Linux-ressourcer både i og uden for Azure, hvilket skaber ægte hybride arbejdsgange:
- Administration af gæstemaskinerKør runbooks direkte på virtuelle Azure-maskiner eller på servere uden for Azure, der er registreret hos Azure Arc (herunder Arc-aktiveret VMware), uanset om det er Windows eller Linux.
- Overvindelse af sandkassens begrænsningerFor operationer, der overstiger grænsen på tre timer i skyen, bruger mange ressourcer eller kræver udvidede tilladelser, leverer Hybrid Workers et miljø. mere fleksibel og uden disse begrænsninger.
- Suverænitets- og sikkerhedskravI organisationer, hvor behandling af bestemte data i skyen ikke er tilladt, kan du opbevare dem Lokale maskiner konverteret til hybridarbejdere og dermed overholde interne og eksterne regler.
- Automatisering i multicloud- og lokale miljøerTilføj blot en maskine som Worker for at starte automatisering på andre maskiner på det lokale netværk eller forskellige cloud-løsninger, både Windows og Linux.
- Privat adgang til tjenester fra VNetsKør runbooks på arbejdere, der er forbundet til et virtuelt Azure-netværk, og få privat adgang til andre tjenester uden at skulle åbne internetforbindelser.
Hvis du vil installere en Hybrid Runbook Worker-instans på Windows eller Linux ved hjælp af den nye udvidelsestilgang, skal du blot følge installationsvejledningen til brug af udvidelser i Azure Automation , som beskriver brugen af VM-udvidelser og Azure Arc til servere.
Netværksplanlægning og serviceetiketter til Hybrid Runbook Worker
Før du åbner porte overhovedet, anbefales det at gennemgå Azure Automation-netværkskonfigurationen , da den angiver porte, URL'er og andre krav, som arbejdere skal opfylde for at kunne kommunikere korrekt med tjenesten.
Azure Automation understøtter virtuelle netværkstjenestetags , startende med GuestAndHybridManagement-tagget. I stedet for at angive specifikke IP-intervaller i NSG- eller Azure Firewall-regler kan du bruge dette tag direkte i kilden eller destinationen for dine regler til at tillade eller nægte trafik til Automation-tjenesten.
GuestAndHybridManagement-tagget dækker IP-adresser, der f.eks. bruges til at udløse webhooks fra et VNet eller til at tillade Hybrid Runbook Worker og State Configuration-agenter at kommunikere med Azure Automation. Det tillader ikke regionsbaserede begrænsninger, men det forenkler netværkssikkerhedsstyringen betydeligt.
Understøttelse af IL5-nyttelaster i Azure Government
Hvis du arbejder med meget høje sikkerhedskrav, understøtter Azure Automation Level 5 Impact (IL5)-arbejdsbelastninger i Azure Government ved hjælp af Hybrid Runbook Worker i to konfigurationer:
- Isolerede virtuelle maskiner der forbruger en hel fysisk vært, hvilket giver det isolationsniveau, der kræves af IL5.
- Azure dedikeret værthvor en eller flere VM'er kører på fysiske servere dedikeret til dit abonnement, hvilket garanterer isolation på hardwareniveau.
Azure Logic Apps (Standard) i hybridtilstand til Windows-Linux-flows
En anden nøglekomponent til at oprette hybride Windows-Linux-arbejdsgange er Azure Logic Apps (Standard) hybridimplementeringsmodellen . Denne mulighed giver dig mulighed for at bygge og hoste integrationsløsninger i delvist forbundne miljøer, der kræver lokal behandling og lagring sammen med intern netværksadgang.
I denne model hostes Logic Apps-kørselstiden på din infrastruktur som en del af en Azure Container Apps-udvidelse og kan placeres på lokale systemer, private clouds eller offentlige clouds og oprette forbindelse til Windows- eller Linux-servere eller SaaS-tjenester.
Nuværende begrænsninger i Logic Apps-hybridmodellen
Når man arbejder i hybridtilstand med Logic Apps Standard, skal der tages højde for visse begrænsninger:
- Den er kun tilgængelig i visse Azure-regioner (Central- og østlige USA, Østasien, Sydøstasien, Centralsverige, Sydlige Storbritannien, Vesteuropa, Vestlige USA, blandt andre anført i den officielle dokumentation).
- I delvist forbundet tilstand kan køretiden forblive afbrudt i op til 24 timer, mens datalogge opretholdesUd over denne periode kan logfiler gå tabt.
- Flere funktioner i single-tenant Logic Apps Standard understøttes ikke i hybrid, f.eks. Implementeringspladser, forretningsprocessporing, ressourcetilstand i portalen eller godkendelse med administrerede identiteter for bestemte forbindelseshandlinger i Azure Arc-aktiverede Kubernetes-klynger.
- Nogle funktionsbaserede udløsere (f.eks. Blob, Cosmos DB eller Event Hubs) kræver konfiguration af lagerkontoforbindelsesstrengen i programvariablen AzureWebJobsStorageenten i Azure Portal eller i local.settings.json-filen i Logic Apps-projektet i VS Code.
Forudsætninger for en hybrid implementering
For at konfigurere en hybrid arbejdsgang med Logic Apps Standard skal du, udover et Azure-abonnement, bruge en række lokale ressourcer på det samme netværk:
- Un Azure Kubernetes Service-klynge forbundet til Azure Arc, som vil fungere som udførelsesplatform for Logic Apps-containere.
- en lokal SQL-database at gemme udførelseshistorikken, input og output fra arbejdsgangene.
- Un SMB-fildeling at gemme de artefakter, der bruges af flowene.
For at udvikle og implementere disse flows er det almindeligt at bruge Visual Studio Code med Azure Logic Apps (Standard)-udvidelsen , som letter redigering, test og publicering i det hybridmiljø, du har konfigureret.
Versionsstyring, telemetri og skalering i hybride Logic Apps
Hver gang du gemmer ændringer i et underordnet flow i en Standard Logic App, der er konfigureret til hybrid hosting, oprettes der automatisk en ny Azure Container Apps-revision . Denne revision kan tage lidt tid at aktivere, så det er en god idé at vente et par øjeblikke, før du tester dine ændringer.
For at overvåge disse arbejdsgange kan du aktivere forbedret telemetri i Application Insights med understøttelse af OpenTelemetry. Dette giver dig realtidspræstationsmålinger og detaljeret indsigt i systemets tilstand, samt kontrol over hvilke data der sendes for at optimere lageromkostninger.
På ressourceniveau kan du justere den hukommelse og de vCPU'er, der er allokeret til Logic App Standard-containeren fra Azure Portal. Du kan variere CPU-kernerne (f.eks. fra 0,25 til 2 vCPU'er) og hukommelsen (f.eks. fra 0,1 til 4 GiB), hvilket direkte påvirker både flowydelse og fakturering.
Du kan også definere skalaen af replikaer, der oprettes som reaktion på udløsende hændelser. Et minimum og maksimum antal replikaer (op til 1000) konfigureres, og mere avancerede skaleringsregler administreres fra Azure Container Apps, så du dynamisk kan tilpasse dig belastningsstigninger i integrationsflows, der påvirker Windows- og Linux-systemer.
Adgang, godkendelse og hemmeligheder i hybridmiljøer
Logic Apps Standard kan eksponeres for det offentlige internet, et VNet eller andre Logic Apps i samme miljø ved at konfigurere indgangsindstillingen. Azure håndterer routing af indgående HTTP- eller TCP-trafik uden at kræve, at du manuelt klargør load balancers eller yderligere offentlige IP-adresser.
I Azure Arc-aktiverede Kubernetes-klynger kan godkendelse af administrerede API-forbindelser ikke bruge administrerede identiteter som standard. I stedet skal du oprette en programregistrering i Microsoft Entra ID og bruge den som grundlag for forbindelser.
- Fra Azure Portal eller Azure CLI opretter du en applikation og indsamler klient-ID, lejer-ID, objekt-ID og klienthemmelighed.
- Derefter lægger du disse værdier til som miljøvariabler i Logic Apps Standard-ressourcen (f.eks. WORKFLOWAPP_AAD_CLIENTID, WORKFLOWAPP_AAD_OBJECTID, WORKFLOWAPP_AAD_TENANTID, WORKFLOWAPP_AAD_CLIENTSECRET).
- Du kan eventuelt gemme clientId og clientSecret som hemmelighederne bag selve ressourcen og derefter referere til dem fra miljøvariabler for større sikkerhed.
Godkendelseslogikken, der er konfigureret på denne måde, tillader hybridflows at kommunikere med Azure API'er og andre beskyttede tjenester, samtidig med at en robust legitimationsmodel opretholdes.
Almindelige problemer og løsninger i hybride Logic Apps
I hybridmiljøer kan der altid opstå overraskelser. For at diagnosticere problemer med miljøkonfigurationen eller mislykkede implementeringer fra portalen udgiver Microsoft et PowerShell-script, troubleshoot.ps1, i det officielle Logic Apps-lager, der gennemgår typiske fejlpunkter.
I Kubernetes-klynger, der er forbundet til Azure Arc, kan der undertiden observeres mønstre med højt hukommelsesforbrug . I sådanne tilfælde anbefales det at skalere nodegrupperne vandret eller aktivere automatisk klyngeskalering.
Hvis Logic App ikke starter korrekt, er det en god idé at kontrollere ressourcestatus fra Azure-portalen, og hvis der er en fejl, skal du bruge kubectl til at kontrollere pods . Meddelelser som "For mange pods" indikerer utilstrækkelig nodekapacitet, mens advarsler om ubundne PersistentVolumeClaims normalt peger på problemer med SMB CSI-driveren . I så fald er installation af smb.csi.k8s.io-driveren ved hjælp af Helm det nødvendige trin, før du fortsætter.
Samlet automatisering med Ansible til Windows og Linux
Ud over Azure-økosystemet er en effektiv tilgang til hybride Windows-Linux-arbejdsgange at bruge Red Hat Ansible Automation Platform (AAP) som et samlet sprog. Ansible nedbryder den historiske adskillelse mellem bash-scripts på Linux og PowerShell eller planlagte opgaver på Windows.
Med én enkelt playbook skrevet i YAML kan du konfigurere, implementere og vedligeholde både Windows- og Linux-servere . Ansible tilbyder native moduler til begge miljøer, der dækker alt fra pakkeinstallation og servicekonfiguration til brugeroprettelse og applikationsimplementering.
For eksempel kan du i en enkelt playbook installere Apache på Red Hat-servere og IIS på Windows-maskiner , starte tjenesterne og aktivere dem ved opstart ved hjælp af operativsystemfamiliebaserede betingelser. Udførelsen koger ned til at lancere en Ansible playbook mod inventaret, der blander begge typer servere.
Dette resulterer i flere klare fordele: færre værktøjer at vedligeholde, standardiserede konfigurationer uanset operativsystem, skalerbarhed til hundredvis af servere med rapportering og versionskontrol og en mærkbar forbedring af sikkerhed og compliance, da alt, hvad der gøres, registreres og kan revideres.
AWS Systems Manager i hybride og multicloud Linux-Windows-miljøer
Hvis en del af dit hybridmiljø ligger på AWS, er Systems Manager et andet værktøj at overveje til at orkestrere arbejdsgange på tværs af Windows- og Linux-noder , der ikke nødvendigvis er EC2-instanser. Nøglen er SSM Agent, som du kan installere på Linux- og Windows-maskiner uden for EC2 ved hjælp af en hybrid aktiveringsproces.
Under aktiveringen genereres et aktiverings-ID og en kode , som knyttes til din AWS-konto. Disse bruges derefter til at registrere hver maskine som en administreret node. På Linux downloader og installerer `ssm-setup-cli`-kommandoen agenten, stopper den og registrerer instansen. Derefter bliver den en administreret node med et id, der typisk starter med "my-" for at skelne den fra EC2-instanser.
Når den er integreret, kan du køre fjernkommandoer, implementere patches, anvende konfigurationer eller endda bruge Change Manager og andre funktioner (husk at nogle, som f.eks. CloudWatch-dashboardet til Systems Manager, har annonceret udtrædelsesdatoer).
SSM Agent kan også konfigureres til automatisk at rotere den private nøgle i hybrid- og multi-cloud-miljøer (startende med version 3.0.1031.0), hvilket styrker sikkerhedsstillingen. Disse indstillinger konfigureres i agentens konfigurationsfil, og hver ændring kræver genstart af tjenesten.
Hvis du har brug for at afregistrere og genregistrere en Linux-node, findes der DeregisterManagedInstance-operationen i AWS CLI, og bagefter anbefales det at rydde poster som IdentityConsumptionOrder i amazon-ssm-agent.json og køre agentens indstilling -register -clear i henhold til installationstypen.
Vedrørende typiske problemer kan koder som DeliveryTimedOut være forventet adfærd, når node-ID'et ændres under en installation på tværs af konti. Fejlmeddelelser om FingerprintDoesNotMatch peger på maskin-ID'er, der ikke bevares efter genstart, hvilket kan løses ved at gennemtvinge generering og bevarelse af maskin-ID'er i Linux.
Windows-applikationer integreret i Linux-skriveborde med WinApps
Det handler ikke kun om backend-processer: mange hybride Windows-Linux-arbejdsgange påvirker brugeroplevelsen direkte. WinApps er et open source-værktøj, der giver dig mulighed for at køre native Windows-programmer fra GNU/Linux-skriveborde (KDE, GNOME, XFCE), som om de var lokale applikationer.
Takket være den problemfri integration kan pakker som Microsoft 365 eller Adobe Creative Cloud køre på en fjern Windows-maskine, men vises og administreres som native Linux-vinduer. For slutbrugeren er ikoner, genveje og vinduer integreret med skrivebordsmiljøet, hvilket reducerer friktion på systemer, der kører begge operativsystemer.
Den enkleste måde at implementere WinApps på er via Docker , ved at bruge det offentligt tilgængelige image og udnytte WorkflowUIPlugin-plugin'et i ComfyUI, når du vil kombinere denne integration med indholdsgenerering eller AI-workflows. Specialiserede virksomheder kan hjælpe med at definere arkitekturer, hvor Linux-desktops bruger Windows-applikationer, der hostes i skyen (AWS, Azure), samtidig med at centraliserede adgangskontroller, cybersikkerhed og overvågning opretholdes.
Hybridt arbejde, samarbejde og moderne udvikling på Microsoft 365 og Windows
Hybride Windows-Linux-arbejdsgange eksisterer ikke isoleret fra mennesker; de er dybt forbundet med, hvordan medarbejdere samarbejder, deler information og udvikler applikationer . Microsoft 365, og især Teams, er blevet det "organisatoriske lag" for mange virksomheder, med millioner af brugere, der arbejder eksternt og i hybride miljøer.
Microsoft kalder mange af disse løsninger for samarbejdsapps : apps, der prioriterer synkront og asynkront samarbejde med møder, chat, samtidig redigering af dokumenter og automatisering af forretningsprocesser, alt sammen integreret i en enkelt brugerflade. For udviklere åbner dette op for en mulighed for at skabe applikationer, der fungerer ensartet på tværs af Windows, macOS, internettet, iOS, Android og Linux.
Teams tilbyder API'er og udvidelsespunkter til avancerede mødeapplikationer (integration af delte faser, mødestart/slutbegivenheder, brugerdefinerede scener i konferencetilstand, medie-API'er med ressourcespecifik samtykke) og integrerer med Azure Communication Services for at give Teams-brugere mulighed for at interagere med eksterne klienter via brugerdefinerede tale-, video- og chatapplikationer.
Derudover forbedres samarbejde på tværs af platforme med Fluid-komponenter i Teams (tabeller, lister og blokke, der kan redigeres i realtid og også deles med Outlook og Office) og genanvendelige beskedudvidelser i Outlook og Teams. Power Platform (Power Apps, Power Automate, Power Virtual Agents) supplerer dette økosystem med bots og low-code-flows, der kan implementeres på Teams.
For at gøre livet lettere for udviklere tilbyder Microsoft et Teams Toolkit til Visual Studio og VS Code med forenklet godkendelse og Graph-brug, integration med Azure Functions og SPFx samt Teams Developer Portal, hvor du kan registrere, konfigurere og administrere applikationer i en centraliseret konsol, herunder aspekter som SaaS-abonnementer og brugsanalyser.
Data, sikkerhed og udvidelsesmuligheder med Microsoft Graph og moderne Windows
I baggrunden er mange af disse samarbejdsoplevelser bygget på Microsoft Graph , som eksponerer kommunikation, indhold og persondata med privatlivs- og sikkerhedskontroller drevet af Azure AD. Nye funktioner såsom kontinuerlig adgangsvurdering muliggør mere øjeblikkelig token-tilbagekaldelse som reaktion på kritiske hændelser, og godkendelsesmetoder og eksterne identitets-API'er giver større kontrol over, hvem der tilgår hvad.
For dem, der har brug for at overføre data til Microsoft 365, giver Microsoft Graph-forbindelser dig mulighed for at indeksere eksterne kilder som Jira eller Confluence, berige brugerprofiler og deltage i oplevelser som Microsoft Search eller eDiscovery. Microsoft Graph-dataforbindelsen muliggør i mellemtiden eksport af produktivitetsdatasæt til Azure til avanceret analyse eller AI-modeltræning.
Inden for desktop-applikationer hjælper Project Reunion (nu en del af moderniseringsstrategien for Windows-apps ) med WinUI 3 og WebView 2, understøttelse af .NET 5 og Windows 10-versioner fra 1809 og fremefter, nye og eksisterende apps med at udnytte Windows-enheder bedre, samtidig med at de integreres med cloud-tjenester.
Værktøjer som Windows Terminal (kan konfigureres som standardterminal med tilstande som Quake) og Windows Subsystem til Linux med understøttelse af GUI-applikationer gør det meget mere bekvemt at udvikle og administrere hybridmiljøer fra Windows ved at blande klassiske CLI'er, Linux-shells og grafiske værktøjer i den samme arbejdsgang.
Afsluttende overvejelser
På den anden side introducerer Power Automate Desktop og funktioner som Process Advisor no-code RPA i Windows 10, hvilket giver dig mulighed for at identificere flaskehalse og gentagne opgaver, der nemt kan automatiseres, ofte i kombination med Linux backend-systemer eller cloudtjenester.
Ved at kombinere alle disse dele – Azure Automation, Logic Apps, Ansible, AWS Systems Manager, WinApps, Teams, Graph og forbedringerne til Windows og WSL – er det muligt at bygge virkelig robuste hybride Windows-Linux-arbejdsgange, hvor automatisering, integration, sikkerhed og samarbejde koordineres, så folk kan fokusere på at levere værdi og ikke kæmpe med usammenhængende værktøjer eller skrøbelige manuelle processer. Del disse oplysninger, så flere kan lære om det.