Dette er det andet indlæg i en serie i fire dele, der beskriver hvordan NatWest Group, en større institution for finansielle tjenesteydelser, som samarbejder med AWS Professional Services at bygge en ny platform til maskinlæringsoperationer (MLOps). I dette indlæg deler vi, hvordan NatWest Group brugte AWS til at muliggøre selvbetjeningsimplementering af deres standardiserede, sikre og kompatible MLOps-platform ved hjælp af AWS servicekatalog , Amazon SageMaker. Dette har ført til en reduktion af den tid, det tager at klargøre nye miljøer, fra dage til kun få timer.
Vi tror på, at beslutningstagere kan drage fordel af dette indhold. CTO'er, CDAO'er, senior data scientists og senior cloud-ingeniører kan følge dette mønster for at levere innovative løsninger til deres datavidenskabs- og ingeniørteams.
Læs hele serien:
|
Teknologi hos NatWest Group
NatWest Group er en relationsbank for en digital verden, der leverer finansielle tjenester til mere end 19 millioner kunder i hele Storbritannien. Koncernen har en mangfoldig teknologiportefølje, hvor løsninger på forretningsmæssige udfordringer ofte leveres ved hjælp af skræddersyede designs og med lange tidslinjer.
For nylig vedtog NatWest Group en cloud-first-strategi, som har gjort det muligt for virksomheden at bruge administrerede tjenester til at levere on-demand computer- og lagerressourcer. Dette skridt har ført til en forbedring af den overordnede stabilitet, skalerbarhed og ydeevne af forretningsløsninger, samtidig med at omkostningerne er reduceret og leveringskadencen accelereret. Derudover giver flytning til skyen NatWest Group mulighed for at forenkle sin teknologistack ved at håndhæve et sæt konsistente, gentagelige og forhåndsgodkendte løsningsdesigns for at opfylde regulatoriske krav og fungere på en kontrolleret måde.
Udfordringer
Pilotstadierne med at anvende en cloud-first-tilgang involverede adskillige eksperimenterings- og evalueringsfaser, hvor der blev brugt en bred vifte af analysetjenester på AWS. De første gentagelser af NatWest Groups cloud-platform til datavidenskabelige arbejdsbelastninger konfronterede udfordringer med at levere konsistente, sikre og kompatible cloudmiljøer. Processen med at skabe nye miljøer tog fra et par dage til uger eller endda måneder. En afhængighed af centrale platformsteams til at bygge, levere, sikre, implementere og administrere infrastruktur og datakilder gjorde det vanskeligt at indbygge nye teams til at arbejde i skyen.
På grund af forskellen i infrastrukturkonfigurationen på tværs af AWS-konti, skulle teams, der besluttede at migrere deres arbejdsbelastninger til skyen, gennemgå en omfattende overholdelsesproces. Hver infrastrukturkomponent skulle analyseres separat, hvilket øgede tidslinjerne for sikkerhedsrevision.
At komme i gang med udvikling i AWS involverede at læse et sæt dokumentationsvejledninger skrevet af platformsteams. De indledende trin til opsætning af miljøet omfattede administration af offentlige og private nøgler til godkendelse, konfiguration af forbindelser til fjerntjenester ved hjælp af AWS kommandolinjegrænseflade (AWS CLI) eller SDK fra lokale udviklingsmiljøer og kører tilpassede scripts til at linke lokale IDE'er til cloud-tjenester. Tekniske udfordringer gjorde det ofte vanskeligt at komme ombord på nye teammedlemmer. Efter at udviklingsmiljøerne var blevet konfigureret, var vejen til at frigive software i produktionen tilsvarende kompleks og lang.
Som beskrevet i del 1 af denne serie indsamlede det fælles projektteam store mængder feedback om brugeroplevelse og krav fra teams på tværs af NatWest Group forud for opbygningen af den nye datavidenskab og MLOps-platform. Et fælles tema i denne feedback var behovet for automatisering og standardisering som en forløber for hurtig og effektiv projektlevering på AWS. Den nye platform bruger AWS-administrerede tjenester til at optimere omkostningerne, skære ned på indsatsen for platformkonfiguration og reducere COXNUMX-fodaftrykket fra at køre unødvendigt store computerjob. Standardisering er indlejret i hjertet af platformen med forhåndsgodkendte, fuldt konfigurerede, sikre, kompatible og genbrugelige infrastrukturkomponenter, der kan deles mellem data- og analyseteams.
Hvorfor SageMaker Studio?
Holdet valgte Amazon SageMaker Studio som det vigtigste værktøj til at bygge og implementere ML pipelines. Studio tilbyder en enkelt webbaseret grænseflade, der giver brugerne fuldstændig adgang, kontrol og synlighed i hvert trin, der kræves for at bygge, træne og implementere modeller. Modenheden af Studio IDE (integreret udviklingsmiljø) til modeludvikling, metadatasporing, artefaktstyring og implementering var blandt de funktioner, der appellerede stærkt til NatWest Group-teamet.
Dataforskere hos NatWest Group arbejder med SageMaker-notebooks inde i Studio under de indledende stadier af modeludvikling for at udføre dataanalyse, datastrid og funktionsudvikling. Når brugerne er tilfredse med resultaterne af dette indledende arbejde, konverteres koden let til komponerbare funktioner til datatransformation, modeltræning, inferens, logning og enhedstest, så den er i en produktionsklar tilstand.
Senere faser af modeludviklingens livscyklus involverer brugen af Amazon SageMaker Pipelines, som kan inspiceres og overvåges visuelt i Studio. Pipelines visualiseres i en DAG (Directed Acyclic Graph), der farvekoder trin baseret på deres tilstand, mens pipelinen kører. Derudover en opsummering af Amazon CloudWatch-logfiler vises ved siden af DAG'en for at lette fejlfindingen af mislykkede trin. Dataforskere får en kodeskabelon, der består af alle de grundlæggende trin i en SageMaker-pipeline. Dette giver en standardiseret ramme (konsistent på tværs af alle brugere af platformen for at lette samarbejde og videndeling), hvori udviklere kan tilføje den skræddersyede logik og applikationskode, der er specifik for den forretningsudfordring, de løser.
Udviklere kører pipelines i Studio IDE for at sikre, at deres kodeændringer integreres korrekt med andre pipelinetrin. Efter at kodeændringer er blevet gennemgået og godkendt, bygges og køres disse pipelines automatisk baseret på en hovedudløser for Git-lageret. Under modeltræning gemmes og spores modelevalueringsmetrikker i SageMaker Experiments, som kan bruges til tuning af hyperparameter. Efter at en model er trænet, gemmes modelartefakten i SageMaker modelregistrering, sammen med metadata relateret til modelbeholdere, data brugt under træning, modelfunktioner og modelkode. Modelregistret spiller en nøglerolle i modelimplementeringsprocessen, fordi det pakker alle modeloplysninger og muliggør automatisering af modelpromovering til produktionsmiljøer.
MLOps ingeniører implementerer administreret SageMaker batch transformation job, som skaleres for at imødekomme krav om arbejdsbelastning. Både offline batchinferensjob og onlinemodeller, der betjenes via et slutpunkt, bruger SageMakers administrerede inferensfunktionalitet. Dette gavner både platforms- og forretningsapplikationsteams, fordi platformsingeniører ikke længere bruger tid på at konfigurere infrastrukturkomponenter til modelinferens, og forretningsapplikationsteams ikke skriver yderligere standardkode for at konfigurere og interagere med computerforekomster.
Hvorfor AWS servicekatalog?
Teamet valgte AWS Service Catalog til at bygge et katalog med sikre, kompatible og forhåndsgodkendte infrastrukturskabeloner. Infrastrukturkomponenterne i et AWS Service Catalog-produkt er prækonfigureret til at opfylde NatWest Groups sikkerhedskrav. Rolleadgangsstyring, ressourcepolitikker, netværkskonfiguration og centrale kontrolpolitikker er konfigureret for hver ressource pakket i et AWS Service Catalog-produkt. Produkterne versioneres og deles med applikationsteams ved at følge en standardproces, der gør det muligt for datavidenskabs- og ingeniørteams at betjene sig selv og implementere infrastruktur umiddelbart efter at have fået adgang til deres AWS-konti.
Platformudviklingsteams kan nemt udvikle AWS Service Catalog-produkter over tid for at muliggøre implementering af nye funktioner baseret på forretningskrav. Iterative ændringer af produkter foretages ved hjælp af AWS Service Catalog-produktversionering. Når en ny produktversion frigives, flettes kodeændringerne sammen med Git-hovedgrenen og øger versionen af AWS Service Catalog-produktet. Der er en vis grad af autonomi og fleksibilitet i at opdatere infrastrukturen, fordi forretningsapplikationskonti kan bruge tidligere versioner af produkter, før de migrerer til den seneste version.
Løsningsoversigt
Følgende arkitekturdiagram på højt niveau viser, hvordan en typisk forretningsapplikationsbrugscase implementeres på AWS. De følgende afsnit går mere i detaljer med hensyn til kontoarkitekturen, hvordan infrastrukturen implementeres, brugeradgangsstyring og hvordan forskellige AWS-tjenester bruges til at bygge ML-løsninger.
Som vist i arkitekturdiagrammet følger konti en nav- og egermodel. En delt platformskonto fungerer som en hub-konto, hvor ressourcer, der kræves af forretningsapplikationsteamets (talte) konti, hostes af platformsteamet. Disse ressourcer omfatter følgende:
- Et bibliotek med sikre, standardiserede infrastrukturprodukter, der bruges til selvbetjeningsinfrastrukturimplementeringer, hostet af AWS Service Catalog
- Docker-billeder, gemt i Amazon Elastic Container Registry (Amazon ECR), som bruges under kørsel af SageMaker-pipeline-trin og modelslutning
- AWS CodeArtifact repositories, som er vært for forhåndsgodkendte Python-pakker
Disse ressourcer deles automatisk med eger-konti via AWS Service Catalog-porteføljedeling og -importfunktion, og AWS identitets- og adgangsstyring (IAM) tillidspolitikker i tilfælde af både Amazon ECR og CodeArtifact.
Hvert virksomhedsapplikationsteam tildeles tre AWS-konti i NatWest Groups infrastrukturmiljø: udvikling, præproduktion og produktion. Miljønavnene henviser til kontoens tilsigtede rolle i datavidenskabens udviklingslivscyklus. Udviklingskontoen bruges til at udføre dataanalyse og skænderier, skrive model- og modelpipelinekode, træne modeller og udløse modelimplementeringer til præproduktions- og produktionsmiljøer via SageMaker Studio. Præproduktionskontoen afspejler opsætningen af produktionskontoen og bruges til at teste modelimplementeringer og batchtransformationsjob, før de frigives til produktion. Produktionskontoen er vært for modeller og kører produktionsinferencing-arbejdsbelastninger.
Brugeradministration
NatWest Group har strenge styringsprocesser for at gennemtvinge adskillelse af brugerroller. Fem separate IAM-roller er blevet oprettet for hver brugerperson.
Platformteamet bruger følgende roller:
- Platform support ingeniør – Denne rolle indeholder tilladelser til business-as-usual-opgaver og en skrivebeskyttet visning af resten af miljøet til overvågning og fejlretning af platformen.
- Platform fix ingeniør – Denne rolle er blevet oprettet med forhøjede tilladelser. Det bruges, hvis der er problemer med platformen, der kræver manuel indgriben. Denne rolle påtages kun på en godkendt, tidsbegrænset måde.
Forretningsapplikationsudviklingsteamene har tre forskellige roller:
- Teknisk leder – Denne rolle er tildelt applikationsteamlederen, ofte en senior dataforsker. Denne bruger har tilladelse til at implementere og administrere AWS Service Catalog-produkter, udløse udgivelser i produktion og gennemgå status for miljøet, som f.eks. AWS CodePipeline status og logs. Denne rolle har ikke tilladelse til at godkende en model i SageMaker-modelregistret.
- Udvikler – Denne rolle er tildelt alle teammedlemmer, der arbejder med SageMaker Studio, som omfatter ingeniører, dataforskere og ofte teamlederen. Denne rolle har tilladelser til at åbne Studio, skrive kode og køre og implementere SageMaker-pipelines. Ligesom den tekniske leder har denne rolle ikke tilladelse til at godkende en model i modelregistret.
- Modelgodkender – Denne rolle har begrænsede tilladelser vedrørende visning, godkendelse og afvisning af modeller i modelregistret. Årsagen til denne adskillelse er at forhindre brugere, der kan bygge og træne modeller, i at godkende og frigive deres egne modeller i eskalerede miljøer.
Separate Studio-brugerprofiler oprettes til udviklere og modelgodkendere. Løsningen bruger en kombination af IAM-politikerklæringer og SageMaker-brugerprofiltags, så brugere kun har tilladelse til at åbne en brugerprofil, der matcher deres brugertype. Dette sikrer, at brugeren tildeles den korrekte SageMaker execution IAM-rolle (og derfor tilladelser), når de åbner Studio IDE.
Selvbetjeningsimplementeringer med AWS Service Catalog
Slutbrugere bruger AWS Service Catalog til at implementere datavidenskabelige infrastrukturprodukter, såsom følgende:
- Et studiemiljø
- Studio brugerprofiler
- Model implementeringspipelines
- Træningspipelines
- Inferensrørledninger
- Et system til overvågning og alarmering
Slutbrugere implementerer disse produkter direkte gennem AWS Service Catalog UI, hvilket betyder, at der er mindre afhængighed af centrale platformsteams til at levere miljøer. Dette har i høj grad reduceret den tid, det tager for brugere at få adgang til nye cloud-miljøer, fra flere dage ned til blot et par timer, hvilket i sidste ende har ført til en betydelig forbedring af time-to-value. Brugen af et fælles sæt af AWS Service Catalog-produkter understøtter sammenhæng i projekter på tværs af virksomheden og sænker barrieren for samarbejde og genbrug.
Fordi al datavidenskabsinfrastruktur nu er implementeret via et centralt udviklet katalog over infrastrukturprodukter, er der sørget for at bygge hvert af disse produkter med sikkerhed i tankerne. Tjenester er blevet konfigureret til at kommunikere inden for Amazon Virtual Private Cloud (Amazon VPC), så trafikken ikke krydser det offentlige internet. Data er krypteret under transport og i hvile ved hjælp af AWS Key Management Service (AWS KMS) taster. IAM-roller er også blevet oprettet for at følge princippet om mindste privilegium.
Endelig, med AWS Service Catalog, er det nemt for platformsteamet løbende at frigive nye produkter og tjenester, efterhånden som de bliver tilgængelige eller kræves af forretningsapplikationsteams. Disse kan tage form af nye infrastrukturprodukter, der for eksempel giver slutbrugere mulighed for at implementere deres egne Amazon EMR klynger eller opdateringer til eksisterende infrastrukturprodukter. Fordi AWS Service Catalog understøtter produktversionering og bruger AWS CloudFormation bag kulisserne kan in-place opgraderinger bruges, når nye versioner af eksisterende produkter frigives. Dette giver platformsteamene mulighed for at fokusere på at bygge og forbedre produkter i stedet for at udvikle komplekse opgraderingsprocesser.
Integration med NatWests eksisterende IaC-software
AWS Service Catalog bruges til selvbetjening af datavidenskabelige infrastrukturimplementeringer. Derudover bruges NatWests standard infrastruktur som kode (IaC) værktøj, Terraform, til at bygge infrastruktur i AWS konti. Terraform bruges af platformsteams under den indledende kontoopsætningsproces til at implementere nødvendige infrastrukturressourcer såsom VPC'er, sikkerhedsgrupper, AWS System Manager parametre, KMS-nøgler og standard sikkerhedskontroller. Infrastruktur i hub-kontoen, såsom AWS Service Catalog-porteføljer og de ressourcer, der bruges til at bygge Docker-billeder, er også defineret ved hjælp af Terraform. Men selve AWS Service Catalog-produkter er bygget ved hjælp af standard CloudFormation-skabeloner.
Forbedring af udviklerproduktivitet og kodekvalitet med SageMaker-projekter
SageMaker projekter give udviklere og dataforskere adgang til hurtigstartsprojekter uden at forlade SageMaker Studio. Disse hurtigstartsprojekter giver dig mulighed for at implementere flere infrastrukturressourcer på samme tid med blot et par klik. Disse inkluderer et Git-lager, der indeholder en standardiseret projektskabelon for den valgte modeltype, Amazon Simple Storage Service (Amazon S3) spande til lagring af data, serialiserede modeller og artefakter og modeltræning og inferens CodePipeline-pipelines.
Introduktionen af standardiserede kodebasearkitekturer og værktøj gør det nu nemt for datavidenskabsfolk og ingeniører at bevæge sig mellem projekter og sikre, at kodekvaliteten forbliver høj. For eksempel er bedste praksis inden for softwareudvikling, såsom linting- og formateringstjek (køres både som automatiserede tjek og pre-commit hooks), enhedstests og dækningsrapporter nu automatiserede som en del af træningspipelines, hvilket giver standardisering på tværs af alle projekter. Dette har forbedret vedligeholdelsen af ML-projekter og vil gøre det nemmere at flytte disse projekter i produktion.
Automatisering af modelimplementeringer
Modeltræningsprocessen orkestreres ved hjælp af SageMaker Pipelines. Efter at modellerne er blevet trænet, gemmes de i SageMaker-modelregistret. Brugere, der er tildelt rollen som modelgodkender, kan åbne modelregistret og finde oplysninger vedrørende træningsprocessen, f.eks. hvornår modellen blev trænet, hyperparameterværdier og evalueringsmetrikker. Disse oplysninger hjælper brugeren med at beslutte, om en model skal godkendes eller afvises. Afvisning af en model forhindrer modellen i at blive implementeret i et eskaleret miljø, hvorimod godkendelse af en model udløser en modelpromoveringspipeline via CodePipeline, der automatisk kopierer modellen til præproduktions-AWS-kontoen, klar til test af arbejdsbelastning. Efter at teamet har bekræftet, at modellen fungerer korrekt i præproduktionen, godkendes et manuelt trin i samme pipeline, og modellen kopieres automatisk over til produktionskontoen, klar til produktionsinferencing arbejdsbelastninger.
Resultater
Et af hovedformålene med dette samarbejdsprojekt mellem NatWest og AWS var at reducere den tid, det tager at levere og implementere datavidenskabelige cloudmiljøer og ML-modeller i produktion. Dette er opnået – NatWest kan nu levere nye, skalerbare og sikre AWS-miljøer i løbet af få timer sammenlignet med dage eller endda uger. Datavidenskabsmænd og ingeniører er nu bemyndiget til selv at implementere og administrere datavidenskabsinfrastruktur ved hjælp af AWS Service Catalog, hvilket reducerer afhængigheden af centraliserede platformsteams. Derudover gør brugen af SageMaker-projekter det muligt for brugere at begynde kodning og træningsmodeller inden for få minutter, samtidig med at der tilbydes standardiserede projektstrukturer og værktøj.
Fordi AWS Service Catalog fungerer som den centrale metode til at implementere data science infrastruktur, kan platformen nemt udvides og opgraderes i fremtiden. Nye AWS-tjenester kan hurtigt tilbydes slutbrugere, når behovet opstår, og eksisterende AWS Service Catalog-produkter kan opgraderes på plads for at drage fordel af nye funktioner.
Endelig betyder bevægelsen mod administrerede tjenester på AWS, at computerressourcer leveres og lukkes ned efter behov. Dette har givet omkostningsbesparelser og fleksibilitet, samtidig med at det er tilpasset NatWests ambition om at være nul i 2050 på grund af en anslået 75% reduktion i CO2 emissioner.
Konklusion
Vedtagelsen af en cloud-first-strategi hos NatWest Group førte til skabelsen af en robust AWS-løsning, der kan understøtte et stort antal forretningsapplikationsteams på tværs af organisationen. Administration af infrastruktur med AWS Service Catalog har forbedret cloud-onboarding-processen betydeligt ved at bruge sikre, kompatible og forhåndsgodkendte byggeklodser af infrastruktur, der nemt kan udvides. Administrerede SageMaker-infrastrukturkomponenter har forbedret modeludviklingsprocessen og fremskyndet leveringen af ML-projekter.
For at lære mere om processen med at bygge produktionsklare ML-modeller hos NatWest Group, tag et kig på resten af denne firedelte serie om det strategiske samarbejde mellem NatWest Group og AWS Professional Services:
- del 1 forklarer, hvordan NatWest Group samarbejdede med AWS Professional Services for at bygge en skalerbar, sikker og bæredygtig MLOps-platform
- del 3 giver et overblik over, hvordan NatWest Group bruger SageMaker-tjenester til at bygge reviderbare, reproducerbare og forklarelige ML-modeller
- del 4 detaljer, hvordan NatWest datavidenskabsteams migrerer deres eksisterende modeller til SageMaker-arkitekturer
Om forfatterne
Junaid Baba er DevOps-konsulent hos AWS Professional Services Han udnytter sin erfaring inden for Kubernetes, distribueret computing, AI/MLOps til accelereret cloud-adoption af kunder i den britiske finansindustri. Junaid har været hos AWS siden juni 2018. Inden da arbejdede Junaid med en række finansielle nystartede virksomheder, der drev DevOps-praksis. Uden for arbejdet har han interesser i trekking, moderne kunst og stillfotografering.
Yordanka Ivanova er dataingeniør hos NatWest Group. Hun har erfaring med at bygge og levere dataløsninger til virksomheder i den finansielle branche. Før hun kom til NatWest, arbejdede Yordanka som teknisk konsulent, hvor hun fik erfaring med at udnytte en bred vifte af cloud-tjenester og open source-teknologier til at levere forretningsresultater på tværs af flere cloud-platforme. I sin fritid nyder Yordanka at træne, rejse og spille guitar.
Michael England er softwareingeniør i Data Science and Innovation-teamet hos NatWest Group. Han brænder for at udvikle løsninger til at køre store Machine Learning-arbejdsbelastninger i skyen. Før han kom til NatWest Group, arbejdede Michael i og ledede softwareingeniørteams, der udviklede kritiske applikationer i de finansielle tjenesteydelser og rejseindustrien. I sin fritid nyder han at spille guitar, rejse og udforske landskabet på sin cykel.
- Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
- Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
- CryptoHawk. Altcoin radar. Gratis prøveversion.
- Kilde: https://aws.amazon.com/blogs/machine-learning/part-2-how-natwest-group-built-a-secure-compliant-self-service-mlops-platform-using-aws-service- katalog-og-amazon-sagemaker/
- "
- 100
- Om
- accelereret
- accelererende
- adgang
- Konto
- tværs
- Desuden
- Yderligere
- Vedtagelse
- Fordel
- Alle
- Amazon
- blandt
- beløb
- beløb
- analyse
- analytics
- Anvendelse
- applikationer
- tilgang
- Godkend
- arkitektur
- Kunst
- tildelt
- revision
- Godkendelse
- Automatiseret
- Automation
- Automatisering og standardisering
- til rådighed
- AWS
- Bank
- bliver
- bag scenen
- være
- gavner det dig
- fordele
- BEDSTE
- bedste praksis
- bygge
- Bygning
- virksomhed
- kulstof
- hvilken
- centraliseret
- udfordre
- udfordringer
- Kontrol
- Cloud
- Cloud platform
- cloud-tjenester
- kode
- Kodning
- samarbejde
- kombination
- Fælles
- Virksomheder
- selskab
- sammenlignet
- komplekse
- Compliance
- kompatibel
- komponent
- Compute
- computing
- Konfiguration
- Tilslutninger
- konsulent
- Container
- Beholdere
- indeholder
- indhold
- løbende
- kontrol
- oprettet
- Oprettelse af
- skabelse
- kritisk
- skik
- Kunder
- data
- dataanalyse
- datalogi
- dataforsker
- leveret
- leverer
- levering
- Efterspørgsel
- krav
- indsætte
- indsat
- implementering
- implementering
- implementeringer
- beskrevet
- designs
- detail
- detaljer
- udviklet
- Udvikler
- udviklere
- udvikling
- Udvikling
- forskellige
- svært
- digital
- direkte
- distribueret
- distribueret computing
- Docker
- Er ikke
- ned
- kørsel
- nemt
- effektiv
- indsats
- Uddybe
- muliggøre
- Endpoint
- ingeniør
- Engineering
- Ingeniører
- Enterprise
- Miljø
- anslået
- evaluering
- udvikle sig
- eksempel
- udførelse
- eksisterende
- erfaring
- Feature
- Funktionalitet
- tilbagemeldinger
- finansielle
- finansielle tjenesteydelser
- Fornavn
- Fix
- Fleksibilitet
- Fokus
- følger
- efter
- Fodspor
- formular
- Framework
- funktionalitet
- fremtiden
- Git
- regeringsførelse
- gruppe
- Gruppens
- Guides
- Gem
- hjælpe
- hjælper
- Høj
- Hvordan
- HTTPS
- Identity
- implementering
- forbedret
- omfatter
- medtaget
- omfatter
- øget
- industrier
- industrien
- oplysninger
- Infrastruktur
- Innovation
- innovativ
- Institution
- integrere
- integreret
- interesser
- grænseflade
- Internet
- involverede
- spørgsmål
- IT
- Karriere
- Nøgle
- nøgler
- viden
- stor
- seneste
- føre
- LÆR
- læring
- Led
- Udnytter
- løftestang
- Bibliotek
- Limited
- Line (linje)
- Linking
- lokale
- maskine
- machine learning
- lavet
- større
- maerker
- administrere
- lykkedes
- ledelse
- styring
- måde
- manuel
- Matter
- modenhed
- betyder
- Medlemmer
- Metrics
- million
- tankerne
- ML
- model
- modeller
- overvågning
- måned
- mere
- bevæge sig
- flytning
- flere
- navne
- netværk
- Nye funktioner
- Ny platform
- nyt produkt
- nye produkter
- nummer
- tilbydes
- offline
- onboarding
- online
- åbent
- Produktion
- Optimer
- organisation
- Andet
- samlet
- egen
- særlig
- partnerskab
- lidenskabelige
- Mønster
- ydeevne
- fotografering
- pilot
- perron
- Platforme
- spiller
- politikker
- politik
- portefølje
- porteføljer
- princippet
- private
- Private nøgler
- behandle
- Processer
- Produkt
- produktion
- produktivitet
- Produkter
- professionel
- Profil
- Profiler
- projekt
- projekter
- forfremmelse
- give
- giver
- leverer
- offentlige
- kvalitet
- Hurtig
- hurtigt
- Læsning
- reducere
- reducere
- lovgivningsmæssige
- forhold
- frigive
- frigivet
- Udgivelser
- afhængighed
- Rapporter
- Repository
- kræver
- påkrævet
- Krav
- ressource
- Ressourcer
- REST
- Resultater
- gennemgå
- R
- Kør
- kører
- Skalerbarhed
- skalerbar
- Scale
- scener
- Videnskab
- Videnskabsmand
- forskere
- SDK
- sikker
- sikkerhed
- valgt
- Series
- tjeneste
- Tjenester
- sæt
- setup
- Del
- delt
- signifikant
- Tilsvarende
- Simpelt
- So
- Software
- Software Engineer
- software Engineering
- løsninger
- Løsninger
- tilbringe
- Stabilitet
- stable
- standard
- nystartede virksomheder
- påbegyndt
- Tilstand
- udsagn
- Status
- opbevaring
- Strategisk
- Strategi
- Studio
- support
- Understøtter
- bæredygtig
- systemet
- Systemer
- opgaver
- hold
- Teknisk
- Teknologier
- Teknologier
- skabeloner
- prøve
- Test
- tests
- leddet
- tema
- derfor
- Gennem
- tid
- værktøj
- mod
- Sporing
- Trafik
- Kurser
- Transform
- Transformation
- transit
- rejse
- Traveling
- Stol
- ui
- Uk
- opdateringer
- brug
- brugere
- udnytte
- Ved hjælp af
- række
- Specifikation
- Virtual
- synlighed
- web-baseret
- hvorvidt
- mens
- WHO
- inden for
- uden
- Arbejde
- arbejdede
- arbejder
- træner
- virker
- world