Der er et stigende behov for at udstille services via API’er, både internt i organisationer samt eksternt til kunder og leverandører. Dermed opstår behovet for at sikre en ensartet måde at udvikle, udstille, dokumentere og vedligeholde API’er på, på tværs af udviklingsteams.
Mange af udfordringerne kan løses ved at benytte koncepterne fra DevOps. I DevOps spiller automatisering en stor rolle hvilket bl.a. indebærer brugen af CI og CD pipelines med fokus på Infrastructure as Code. Den nyeste tankegang for udvikling af API’er, er døbt APIOps.
Bloggen her beskriver vores erfaringer med APIOps og hvilke fordele man opnår ved denne tilgang. Både generelt og specifikt ved brug af Azure API Management og Azure DevOps, som det tekniske fundament.
Til håndtering af API’er har Microsoft udviklet platformen Azure API Management (APIM). Platformen er designet til at hjælpe med at håndtere de problemstillinger, der er når man vil eksponere API’er. Azure APIM kan bl.a. hjælpe på følgende:
En portal med et overblik over alle API’er eksponeret på platformen.
Azure APIM er cloud-agnostisk, dvs. API’erne kan være hostet on-premises eller hvilken som helst cloud
Understøtter ‘API-first' tilgang til udvikling
Monitorering og logning af API’er
Sikkerhedsstandarder for alle API’er
Authentication og authorization
At samle forskellige API’er i en Azure APIM instans muliggør at have en standardiseret og ensartet sikkerhed på tværs af API’erne. Dermed behøver man kun implementere disse ting én gang og man sikrere sig, at alle API’er har de samme standarder, modsat at forskellige team har implementeret på forskellig måde.
Azure APIM består af 2 hoveddele. En developer portal og en gateway.
Developer portalen er brugergrænsefladen hvor forbrugere af API’er kan både se og finde nye API’er samt abonnere på dem. Developer portalen giver desuden mulighed for at teste API’er direkte i browseren. Nogle API’er kan opsættes så de kræver godkendelse før de kan benyttes, eller være usynlige, alt efter hvilken adgang brugeren har.
Gateway’en er det end-point, som alle forbrugere af API’er på platformen skal ramme. Gateway'en henter API’erne fra Management Plane hvor der kan været defineret kriterier som fx policies. Igennem policies kan man fx definere throttling og validering af requests, så man sikrer sig mod at få ondsindede requests igennem til sin backend. Derefter videregiver gateway’en request’en til backend'en.
APIOps slår koncepterne DevOps og GitOps sammen og bruger dem til at facilitere udvikling, testing og deployment af API’er. Ved at automatisere og bl.a. benytte Infrastructure As Code (IaC) principper, gør APIOps det muligt at:
Sikre hurtigere, nemmere og mere sikker levering af API’er
Faciliterer at have multi-tenancy på en APIM platform
Forhøje kvaliteten af API’er igennem automatiserede test af f.eks. validering, linting, breaking change detektering, dokumentationskrav ect.
Hvis vi tager disse fordele og kombinerer dem med de fordele som Azure APIM giver, så får vi pludselig API’er, der både overholder compliance, er funktionelle, samt nemme at finde. Det er essensen af hvad et velfungerende API bør kunne, som det også er beskrevet af Melissa Van Der Hecht her.
For at opnå APIOps med Azure APIM skal man have styr på governance, samt sin infrastruktur. Det gør man ved at benytte sig af versioneringsstyring og IaC. Dvs. alle ændringer der skal laves til en APIM-instans, som fx deployment af et nyt API eller opdatering af et API, håndteres med Git og pipelines i Azure DevOps, fremfor en manuel ændring via Azure portalen.
Alle ændringer kan styres gennem pull request ind mod den branch, som repræsenterer den nuværende konfiguration af det API, der er deployet. Ved at benytte pull request er det muligt at konfigurere regler, e.g., validering og linting, som skal overholdes inden pull requested må merges. Når reglerne er overholdt kan ‘merget’ gennemføres hvorved API’et automatisk bliver deployet via Azure DevOps. Ved at bruge IaC kan vi sørge for, at vi altid bruger de samme policies, de rigtige authentication metoder osv. når vi ‘deployer’ et API.
Deployment af selve APIM platformen sker også ved benyttelse af IaC, hvilket gør det nemt at have flere miljøer, f.eks., udvikler-test, forbruger-test og produktionsmiljøer. Deployment til de forskellige miljøer kan styres igennem forskellige branches og pipelines. Dette gør det muligt, at facilitere en hurtig og nem udviklingsproces for API-udviklere.
Hvis man er vant til at arbejde med DevOps, så lyder det hele nok bekendt. Med Azure API Mangement kombineret med DevOps-dyderne, så er man godt på vej.
Azure APIM er ikke designet med multi-tenancy. Derfor ligger det mere op til at man har en APIM pr. team, hvilket hurtigt bliver dyrt, da APIM er en dyr ressource. Microsoft har lavet deres eget forslag til hvordan sådan et multi-tenancy system kan se ud, som fx kan ses på billedet ovenover.
Microsofts tilgang bygger på at API-udviklere kan bygge en API template ud fra deres API Spec eller deres egen APIM instans. I cVation har vi taget en lidt anderledes tilgang til multi-tenancy end den foreslået af Microsoft. I stedet har vores tilgang været et abstraktionsniveau højere. På den måde slipper API-udviklere først og fremmest for at skulle forstå og designe policies og API ressource skemaer og skal blot uploade et API spec. Samtidig muliggør det, at vi kan tilbyde nogle out-of-the-box features, for at garantere ensartethed og kontrol med hvordan et API ser ud.
Abstraktionen har muliggjort at APIM instansen og API’erne bliver deployet separat, fra hver deres repositorie. Vi har på den måde mulighed for at give API-udviklerne fuld autonomi inden for organisationens regler og guidelines. Alle repositories deployer til den samme APIM instans, ved hjælp af IaC, versionskontrol og vores regler, så vil alle API’er blive deployet på samme måde.
Hvis man er vant til at arbejde efter DevOps principperne, så kan man overføre metoderne til API’er og med fordel kombinerer det med Azure API Management. På den måde kommer man nemt i mål og kan høste alle fordele ved APIOps uanset hvilken organisation man sidder i.
Mulitenancy delen skal man dog være særligt opmærksom på hvordan man håndterer, og som beskrevet har valget stor betydning for omkostningerne på løsningen.