Vad är databas-som-tjänst (DBaaS)?
När vi pratar om databaser som konsumeras som molntjänster, pratar vi om Database-as-a-Service (DBaaS).
Även om detta inte är en silverkula som kommer att förenkla livet för alla som behöver en databas för något uppgifts- eller applikationsutvecklingsprojekt, är DBaaS inte bara enkelt, det är flexibelt.
Det har många fördelar och nackdelar som är gemensamma för andra tjänster i molnet, till exempel bättre kostnadskontroller å ena sidan men mer begränsade funktioner än det lokala alternativet å andra sidan.
Det fungerar emellertid också som motorprogramvara som driver ett stort utbud av andra SaaS-appar (Software-as-a-Service), allt från direktrelaterade datavisualiseringsverktyg till organisationsomfattande företagsresursplaneringsplattformar (ERP).
Men DBaaS är också en lösning för sig själv med fördelar och nackdelar som är unika för databasfunktioner.
Fördelarna med DBaaS inkluderar lägre inträdesbarriärer, större tillgång till teknik som tidigare bara var inom räckhåll för stora företag och digitalt infödda användningsfall som IoT-datastreaming, maskininlärning (ML) och hybridappar som ett komplement till datorkunskap.
Nackdelarna med DBaaS inkluderar databasernas allmänna styvhet, komplexiteten i datavetenskap, oflexibilitet i integrationer, nätverksprestandafrågor och komplexiteten som följer med stora dataöverföringar.
Om du flyttar känslig data mellan din DBaaS-leverantör och någon annan webbplats måste du också vidta säkerhetsåtgärder, vilket kan innebära allt från robusta identitetshanteringsprotokoll till implementering av ett virtuellt privat nätverk (VPN).
Dessutom finns det olika typer av DBaaS-leverantörer från de som inte gör något annat till storskaliga molntjänster eller webbhotell för vilka en databas bara är en tjänst av många.
Att välja den bästa leverantören bland en sådan lista innebär att man söker igenom en lång lista med variabler, inklusive pris, geografisk närhet, support och till och med de slutgiltiga uppgifter databasen är tänkt att utföra.
Alla dessa begränsningar kan leda till det verkliga behovet av hjälp från en databasadministratör (DBA) trots många DBaaS-leverantörers påståenden att deras plattformar är självbetjäna och användarvänliga.
Slutsatsen är att datavetenskap inte är lätt, även om databasens spin-up och konfiguration är automatiserad som i en eller annan grad i DBaaS-erbjudanden.
Men det finns DBaaS-produkter och tjänster som är lättare att använda än andra, och vissa ligger säkert inom befogenheterna för genomsnittliga utvecklare och affärsanalytiker.
Jag genomförde granskningarna i denna sammanfattning ur utvecklare och analytiker och i mindre utsträckning små till medelstora företag (SMB) med få interna IT-resurser.
Målet med detta projekt var inte att identifiera överlägsenhet ur ett strikt tekniskt perspektiv, utan att identifiera hur väl en typisk användare sannolikt kommer att kunna använda tjänsten, utan hjälp av en DBA, samtidigt som teknikens fulla nytta bibehålls.
Om recensionerna gjordes enbart på grundval av tekniska aspekter kan leverantörsrankingen ha varit annorlunda.
Vad "lätt att använda" betyder verkligen i en DBaaS
Som med alla andra SaaS-erbjudanden är DBaaS faktiskt programvara på någon annans servrar.
Det är sant även i de tyvärr namngivna "serverlösa" modellerna.
Hänsynen till "lättanvänd" här gäller mer än bara om användargränssnittet är användarvänligt eller inte, men också för följande:
- Oavsett om vägledning erbjuds om vilken databastyp eller motor som passar data eller arbetsbelastning,
- Hur enkelt det är att ladda och överföra data,
- Hur mycket av serverprovisionen och servicekonfigurationen hanteras av ML och automatisering, och
- Hur mycket av säkerhetskopierings- och återställningsprocessen är automatisk.
Om användaren måste göra en lång lista med beslut helt enkelt för att konfigurera databasen, är det inte riktigt enkelt att använda för icke-DBA oavsett hur många rullgardinsmenyer och förklaringsrutor som UI har.
Det kan dock vara lätt för DBA att använda och det är också bra, men för andra ändamål och en annan typ av granskning.
Med andra ord, för att en DBaaS ska vara en stark självbetjäningsplattform måste den eliminera behovet av att en DBA är praktisk med varje liten användarinteraktion.
Å andra sidan, om det ska vara ett alternativt eller hybridtillägg till en lokal databas eller till och med ett företags primära databas (som ofta är fallet med molnföretag), är det enkelt för DBA att använda och bildskärmen bör vara de främsta övervägandena.
Till exempel, om ditt företag har kört en instans av Microsofts SQL Server lokalt under några år och nu väljer att lägga till en instans av Microsofts Azure SQL Database som ett molnbaserat reservförvar, kommer de flesta av dina slutanvändare behöver aldrig röra den instansen.
På samma sätt, om databasens primära uppgift kommer att vara att driva en annan app eller ett arbetsflöde, behöver användare inte ofta interagera med det direkt.
När allt kommer omkring, när en databas är igång, kan användare använda verktyg som Business Intelligence (BI), utvecklare och DevOps-appar för att utföra det arbete de verkligen är intresserade av.
Databasen förblir i bakgrunden för de flesta av dessa scenarier.
, och även avancerade användare andra än DBA behöver sällan röra vid den.
Som sagt, användarvänligheten i den här översynen inkluderar hela spektrumet av tjänster som erbjuds.
Tjänsten låter utvecklare, analytiker och enstaka SMB-generella teknologer spinna upp databaser i farten, med få instruktioner och lite mer till hands än ett kreditkort och en internetansluten bärbar dator.
Enligt dessa parametrar är Microsoft Azure SQL Database den enklaste att använda, med MongoDB Atlas som kommer på nära håll.
Att bestämma vilka av dessa två Editors 'Choice-vinnare du vill använda kommer att ha mer att göra med din datas nuvarande format och de projekt du arbetar med än användarvänlighet.
IBM Db2 on Cloud är också lätt att använda, även om det finns många utvecklare som kan tigga om att skilja sig.
De flesta av de gripande handlar om designbegränsningar för utvecklare.
Leverantörerna är inte lika med avseende på antalet regioner som erbjuds.
Färre alternativ kan visa sig vara en nackdel i vissa scenarier för överensstämmelse med Europeiska unionens allmänna dataskyddsförordning (GDPR).
De varierar också när det gäller att följa andra regler, med vissa som fortfarande arbetar med dessa frågor och andra kommer snabbt ombord.
Ett exempel på detta: Från och med juni 2018 uppfyller MongoDB Atlas nu Health Portability and Accountability Act (HIPAA).
Testa versioner och betydelsen av regioner
Granskningen av varje produkt innehåller noteringar om testversion eller gratisversioner är tillgängliga och eventuella begränsningar som kan gälla.
MongoDB Atlas har till exempel en "gratis för alltid" -version med 512 MB lagring och delat RAM-minne.
IBM Db2 on Cloud har en gratis utvecklarversion med företagsfunktioner, men Express-C, dess kostnadsfria kommersiella version, saknar avancerade företagsfunktioner.
Betalda versioner varierar mindre eftersom de oftast är kopplade till lagrings- och datoranvändning snarare än till funktioner.
Det är dock viktigt att notera vilka funktioner och regioner som finns i de olika versionerna innan du väljer en.
Uppenbarligen, om den inte har avancerade företagsfunktioner som IBM Db2 på Clouds Express-C-version och du behöver dem, kommer den versionen inte att fungera.
På samma sätt, om du har problem med GDPR att ta itu med, eller många användare runt om i världen och du verkligen behöver utrota fördröjning på din app, kommer Microsoft Azure SQL Databases fantastiska 50 regioner runt om i världen i 140 länder att betyda lika mycket som att ha fler versionalternativ gör.
När det gäller dina alternativ med avseende på regioner har MongoDB Atlas 56.
Den använder regionerna från Amazon Web Services (AWS), Google Cloud och Microsoft Azure bra eftersom det är värd för alla tre.
Och kontraintuitivt kom Google BigQuery med minst antal regioner.
Att kunna välja regionplats för din databas är viktigt av två skäl.
För det första, på grund av regler som GDPR, måste du vara säker på var dina data finns (även i molnet), vart de rör sig och hur de används.
Att kunna välja rätt plats för din databas är absolut nödvändigt för att förbli GDPR-kompatibel, även om du inte har någon europeisk (EU) kundinformation eller EU-personalinformation.
Flera scenarier gäller här.
Till exempel kan en anställd vara amerikansk och därmed påverkas hans data inte av GDPR.
Hans fru kan vara europeisk eller amerikansk men deras barn kan ha dubbelt medborgarskap om han eller hon är född i Europa.
Så, försäkringsuppgifter om dem påverkas av GDPR.
Därför, även om företaget inte har någon EU-kund eller EU-anställdas uppgifter, är det fortfarande nödvändigt att följa GDPR.
Den lagen är allvarligt komplex.
Och det finns en annan, ännu mer komplex integritetslag från EU som kommer ner i gädden.
Det är därför klokt att veta exakt var dina uppgifter är och vad som händer med och med det, oavsett om du inte tror att du inte har någon EU-information att oroa dig för.
Ju närmare dina data och din app är till varandra, desto bättre är prestandan - vilket betyder, desto kortare fördröjning och andra problem.
Du vill leta efter alternativ för att distribuera din app i samma datacenter som din databas eller samla din databas bredvid din app.
Versioner skiljer sig också väsentligt mellan leverantörer och även inom en enskild leverantörs produktutbud.
Vissa är billiga på framsidan men tar upp kostnader genom att ta betalt för olika verktyg och serviceuppgraderingar, till exempel ytterligare säkerhet eller säkerhetskopiering och återställningstjänster.
Se upp för det.
För den här översynen använde jag mest testkonton i mellannivå som skapades av leverantörerna snarare än de mer begränsade versionerna eller testversionerna.
Ibland överförde jag mina egna testdata och ibland laddade jag leverantörstestdata eller arbetade med deras förinstallerade datamängder.
I många fall tillhandahöll leverantörer krediter för att se till att jag kunde testa deras system noggrant.
Ibland testade jag gratis utvecklarutgåvor, som jag gjorde med SAP Cloud Platform, SAP HANA Service eftersom de vanligtvis är fullfjädrade.
I varje fall noteras den version jag testade i varje recension.
SQL eller NoSQL?
En annan faktor som gör direkta jämförelser svårare i denna översiktliga sammanfattning är i databaser.
Som alla datapersonal vet hanterar SQL strukturerad data och NoSQL är för ostrukturerad data, men den skillnaden är förmodligen inte uppenbar för allmänna användare.
Ett exempel på strukturerad data är ett kalkylark medan ett exempel på ostrukturerad data är Twitter-slangbranden.
SQL-databaser kallas vanligtvis relationsdatabaser medan NoSQL-databaser kallas icke-relaterade.
Men när det gäller DBaaS är alternativen mer varierade än att bara göra en strukturerad kontra ostrukturerad databestämning.
Till exempel, MongoDB Atlas, som är öppen källkod NoSQL, körs på andra molntjänster som AWS, Google och Microsoft.
Vissa leverantörer guidar dig genom labyrinten ...
