Durant dos mòduls sencers, db-reservas ha estat una caixa amb una etiqueta. Apareixia al diagrama de xarxa dins de snet-datos, l'aplicació d'App Service s'hi connectava mitjançant una cadena de connexió i el punt de connexió privat pe-sql-reservas li reservava el lloc. Però encara ningú no ha decidit què és aquesta caixa per dins, i aquesta decisió —presa en una reunió de mitja hora o heretada d'«allò que ja fèiem servir»— és la que surt més cara de corregir després.

Canviar la mida d'una màquina virtual costa cinc minuts. Canviar un pla d'App Service, dos clics. Canviar el motor de base de dades d'una plataforma en producció és un projecte de mesos: cal reescriure consultes, migrar dades històriques, tornar a formar l'equip i aturar la venda de bitllets durant la finestra de tall. Per això aquesta lliçó no desplega res: construeix el criteri. Al final tindràs el mapa de dades complet de Contoso Airlines, amb una decisió raonada per sistema, i cadascuna d'aquestes decisions serà una lliçó d'aquest mòdul.

Avís de cost: aquesta lliçó és purament de disseny i no crea cap recurs, així que no genera factura. A partir de la següent sí: les bases de dades són entre els recursos més cars d'Azure i, a diferència d'una màquina virtual, moltes no es poden aturar. Llegeix sempre l'apartat de cost abans d'executar un az ... create.

1. La decisió que realment falla als projectes
2. Relacional davant de NoSQL: quina pregunta respon bé cada model
3. Gestionat (PaaS) davant d'instal·lat en una VM (IaaS)
4. El catàleg de dades d'Azure en una taula de decisió
5. Els criteris que decideixen
6. Consistència davant de latència: el teorema CAP en termes pràctics
7. Com es factura una base de dades al núvol
8. El mapa de dades de Contoso Airlines
9. Errors Comuns i Consells
10. Exercicis
11. Conclusió

Als projectes de migració al núvol que acaben malament, el punt de fallada gairebé mai no és el còmput. És la dada. I gairebé sempre per un d'aquests tres motius:

• Es tria per moda, no per pregunta. «Farem servir NoSQL perquè escala» és una frase buida si ningú no ha escrit abans quines consultes farà l'aplicació. NoSQL escala per als accessos que el seu disseny va preveure; per a la resta és pitjor que una base relacional.
• Es tria per inèrcia. «Sempre hem fet servir SQL Server, doncs hi posem SQL Server». De vegades és la resposta correcta —la compatibilitat és un criteri legítim i potent—, però ha de ser una conclusió, no un punt de partida.
• Es tria una sola base de dades per a tot. És l'error més car. Una plataforma real té diversos sistemes amb necessitats oposades, i forçar-los tots al mateix motor significa que cap no funciona bé. Fer servir el magatzem adequat per a cada càrrega s'anomena persistència poliglota, i és exactament el que farà Contoso.

La pregunta correcta no és «quina base de dades és millor?», sinó «quines preguntes he de respondre, amb quina freqüència, sobre quantes dades i en quant de temps?».

Un model relacional organitza les dades en taules de files i columnes amb un esquema fix, relacions declarades mitjançant claus foranes i transaccions ACID. El seu superpoder és la consulta arbitrària: pots creuar taules que ningú no havia previst que es creuarien i el motor trobarà la manera de resoldre-ho.

NoSQL no és un model, sinó una família de models que renuncien a part d'això a canvi d'escala, flexibilitat d'esquema o latència:

Dos aclariments que eviten malentesos habituals:

• NoSQL no vol dir «sense esquema», vol dir «sense esquema imposat pel motor». L'esquema continua existint: viu al codi de l'aplicació, que és un lloc pitjor per vigilar-lo.
• NoSQL no vol dir «sense transaccions». Cosmos DB té transaccions ACID, però només dins d'una mateixa partició lògica. La diferència és en l'abast, no en l'existència.

Pots instal·lar PostgreSQL en una màquina virtual de les que vas desplegar a la lliçó 02-01. Funcionarà. La pregunta és quina feina estàs acceptant a canvi de quin control, aplicant el model de responsabilitat compartida del mòdul 1:

La regla pràctica és simple: fes servir PaaS llevat que tinguis un motiu concret i escrit per no fer-ho. Els motius legítims existeixen —una versió antiga no admesa, un agent de tercers que exigeix instal·lar-se al servidor, funcionalitats de SQL Server que només hi ha a la instància completa, o un requisit de llicenciament—, però són minoria. El cost per hora d'una VM sembla menor fins que hi sumes les hores de la Marta Ríos apedaçant servidors un diumenge.

Aquest és el mapa complet del que Azure ofereix per a dades. Llegeix-lo com una taula de decisió, no com un catàleg de venda:

Redis i Table Storage apareixen aquí perquè completen el mapa, però no tenen lliçó pròpia en aquest mòdul: Table Storage ja es va veure a 02-04 i Redis es farà servir com a memòria cau al mòdul 6.

Quan cal justificar una tria davant d'un comitè —i a Contoso cal fer-ho, perquè la Nuria Peña apareixerà al mòdul 8 preguntant per la factura— convé puntuar sis criteris:

1. Model de dades. Les dades tenen forma de taula amb relacions, de document autocontingut, de clau-valor o de graf? Escriu tres consultes reals que l'aplicació farà i comprova si el model les respon de manera natural.
2. Consistència davant de latència. Ho desenvolupem a l'apartat següent.
3. Volum i creixement. No el d'avui: el d'aquí a tres anys. Contoso guarda uns 40 GB de reserves actives i creix 12 GB l'any; això hi cap de sobres en qualsevol opció. Els registres d'esdeveniments d'embarcament, en canvi, creixen 200 GB l'any i descarten tots sols la base relacional.
4. Patró de lectura i escriptura. Lectures o escriptures dominants? Accés per clau o per consulta complexa? Pics previsibles? El catàleg de tarifes es llegeix milers de vegades per minut i s'escriu dues vegades al dia: un cas ideal per a document amb memòria cau.
5. Compatibilitat amb el que ja existeix. El portal de continguts de Contoso és WordPress i parla MySQL. Reescriure'l perquè parli una altra cosa no aporta cap valor de negoci.
6. Cost i habilitats de l'equip. Un motor que ningú no sap operar és una incidència esperant el seu torn. El Diego Salas coneix SQL Server i PostgreSQL; ningú de l'equip no ha tocat mai Cassandra, cosa que descarta aquesta API de Cosmos DB sense més discussió.

El teorema CAP diu que un sistema distribuït no pot garantir alhora consistència (C), disponibilitat (A) i tolerància a particions de xarxa (P). Com que la xarxa sempre es pot partir, la tria real és: quan dos centres de dades deixen de veure's, prefereixes donar una dada possiblement desactualitzada o negar el servei fins a estar segur?

Traduït al negoci de Contoso, amb dos exemples que porten a respostes oposades:

• Places lliures d'un vol. Si dos servidors discrepen, es venen dos bitllets per al mateix seient i algú es queda a terra, amb compensació regulada per la normativa europea. Aquí es tria consistència: millor un error que un seient venut dues vegades.
• Nombre de punts de fidelització mostrats al perfil. Si un passatger veu 12.400 punts i el saldo real ja és 12.550 perquè el vol d'ahir s'acaba de liquidar, no passa res: en uns segons es corregeix. Aquí es trien latència i disponibilitat.

La conseqüència pràctica és que la resposta no és del sistema, sinó de la dada: la mateixa aplicació pot tenir dades que exigeixen consistència estricta i dades que toleren retard, i per això acaba fent servir dos magatzems diferents. A la lliçó 03-03 veuràs que Cosmos DB no obliga a triar d'una vegada per sempre: ofereix cinc nivells de consistència, fins i tot ajustables per petició.

Totes les bases de dades gestionades d'Azure facturen per les mateixes quatre dimensions, encara que cadascuna les anomeni diferent:

La distinció que més diners estalvia és aprovisionat davant de sense servidor:

• Aprovisionat: reserves una capacitat fixa i la pagues les 24 hores, es faci servir o no. És el correcte per a càrrega sostinguda i previsible, com db-reservas en producció.
• Sense servidor: pagues pel consum real per segon i, si el motor ho admet, la base es pausa quan fa una estona que no té connexions i deixa de facturar còmput (l'emmagatzematge es continua pagant sempre). És el correcte per a desenvolupament, proves i càrregues intermitents.

El càlcul de tovalló que farà Contoso: l'entorn de desenvolupament es fa servir unes 45 hores a la setmana de les 168 que té. Pagar aprovisionat significa llençar el 73 % de la despesa. Amb sense servidor i pausa automàtica, aquest 73 % desapareix de la factura sense que ningú canviï la seva manera de treballar.

I un avís que es repetirà a tot el mòdul: una base de dades aprovisionada no es pot «apagar» com una VM. No existeix l'equivalent a l'estat desassignat de la lliçó 02-01. Si deixes creat un servidor de proves i te n'oblides, continua facturant cada hora fins que l'eliminis.

Aplicant els sis criteris als cinc sistemes de l'aerolínia, aquest és el resultat, i també el guió de la resta del mòdul:

És persistència poliglota: cinc magatzems perquè hi ha cinc preguntes diferents. El diagrama complet, amb la xarxa del mòdul 2 al fons:

Fixa't en les fletxes discontínues: l'analítica mai no consulta directament la base operativa. És el principi que justifica l'apartat 1 de la lliçó 03-06.

• Triar el motor abans d'escriure les consultes. Si no pots enumerar les cinc consultes més freqüents de la teva aplicació, no tens prou informació per decidir. Escriu-les primer, encara que sigui en llenguatge natural.
• Fer servir NoSQL per evitar dissenyar el model. La flexibilitat d'esquema no elimina el disseny: el trasllada al codi, on no hi ha cap motor que validi res. Al cap de sis mesos conviuen quatre formes diferents del mateix document.
• Ficar dades analítiques a la base operativa. Un informe de rendibilitat de tres anys llançat contra db-reservas a les 11 del matí degrada la venda de bitllets per a tots els clients. Separa'ls des del principi.
• Oblidar que la base de dades no s'apaga. Aquest és l'error que més apareix a les primeres factures: es creen tres servidors per «provar» i encara hi són un mes després. Aplica sempre les etiquetes obligatòries (entorno, proyecto, centro-coste, propietario) per poder localitzar el responsable de cada recurs.
• Ignorar les habilitats de l'equip. El motor teòricament òptim que ningú no sap diagnosticar a les tres de la matinada és pitjor que el motor correcte que tothom coneix.
• Consell: documenta cada decisió amb una fitxa d'una pàgina (context, opcions, decisió, conseqüències). Quan d'aquí a dos anys algú pregunti per què les tarifes són a Cosmos DB, aquesta pàgina estalviarà una setmana de discussió.
• Consell: si dubtes entre relacional i document i el volum és moderat, comença per relacional. Afegir un magatzem de documents després és senzill; reconstruir la integritat referencial que mai no vas tenir, no.

Contoso Airlines planteja cinc necessitats addicionals. Per a cadascuna, tria el servei de dades i justifica-ho amb almenys dos dels sis criteris:

1. Desar cada esdeveniment d'escaneig de targeta d'embarcament a les portes: uns 90 milions de registres l'any, escriptura constant, consulta posterior només per número de vol i data.
2. Posar a la memòria cau el resultat de la cerca «BCN → LHR, 12 de juliol» durant 60 segons per no colpejar l'API a cada tecleig de l'usuari.
3. Emmagatzemar els contractes en PDF signats amb les agències de viatges, uns 400 l'any, amb cerca per nom d'agència.
4. Un sistema nou de recomanació de rutes alternatives davant de cancel·lacions, que necessita trobar camins entre aeroports amb un màxim de dues escales.
5. L'estat en temps real dels 38 avions de la flota, actualitzat cada 5 segons i consultat pel tauler d'operacions.

Justifica en cada cas si Contoso ha de fer servir un servei gestionat o una màquina virtual:

1. Una aplicació de manteniment d'aeronaus que exigeix SQL Server 2016 amb un agent d'auditoria d'un fabricant extern que s'instal·la com a servei de Windows.
2. Una base de dades nova per al programa de fidelització, sense dependències heretades.
3. Una instància de SQL Server amb 14 bases de dades que avui es comuniquen entre si amb consultes entre bases i treballs de l'Agent SQL.

L'equip proposa aquest entorn de desenvolupament: una base relacional aprovisionada de 4 vCore encesa tot el mes (uns 480 € al mes en tarifa de llista aproximada), 100 GB d'emmagatzematge i retenció de còpies de 35 dies.

1. Quin canvi d'un sol paràmetre elimina més despesa, sabent que l'equip treballa 45 hores setmanals?
2. És raonable una retenció de 35 dies en desenvolupament? Què proposaries?
3. Quina comprovació faries cada dilluns per evitar bases oblidades?

Solució 1:

Solució 2:

1. VM (IaaS), o com a mínim cal valorar-la seriosament: l'agent extern necessita instal·lar-se al sistema operatiu, i en PaaS no hi ha sistema operatiu al qual accedir. Abans de rendir-se convé comprovar si el fabricant té versió compatible amb PaaS.
2. PaaS, Azure SQL Database. No hi ha dependències que lliguin i s'aprofiten còpies automàtiques, apedaçament i alta disponibilitat sense feina operativa.
3. SQL Managed Instance. És el cas per al qual existeix: admet consultes entre bases i SQL Agent —que Azure SQL Database no ofereix— sense renunciar al model gestionat. Migrar a Azure SQL Database obligaria a reescriure aquestes 14 aplicacions.

Solució 3:

1. Passar el nivell a sense servidor amb pausa automàtica. Amb 45 hores d'ús sobre 168, es factura còmput aproximadament el 27 % del temps: l'estalvi ronda el 70 % de la partida de còmput, sense canviar res de la feina diària de l'equip. És exactament la configuració que Contoso adoptarà per a db-reservas a rg-contoso-reservas-dev.
2. No, és excessiva. En desenvolupament, les dades són sintètiques i regenerables: 7 dies són suficients i redueixen la partida de còpies de seguretat. Els 35 dies tenen sentit en producció, on hi ha obligació legal i dades irrepetibles.
3. Llistar els recursos sense les etiquetes obligatòries o amb entorno=dev creats fa més d'una setmana, i reclamar-ho al propietario. Amb Azure CLI es resol amb az resource list --tag entorno=dev --query "[].{n:name, t:type}" -o table, aprofitant el filtratge JMESPath de la lliçó 01-06. Al mòdul 4 això s'automatitzarà amb Azure Policy, i al 8 amb Cost Management.

Aquesta lliçó no ha creat ni un recurs, i tot i així és la que més diners pot estalviar a Contoso Airlines. Ara saps per què la tria del magatzem de dades és la decisió menys reversible d'una arquitectura i per què falla gairebé sempre pels mateixos tres motius: moda, inèrcia o voler un únic motor per a tot. Distingeixes el model relacional de les quatre famílies NoSQL —document, clau-valor, graf i columnar— per la pregunta que respon bé cadascuna, no pel seu eslògan. Tens en taula el que guanyes i el que perds en passar d'una base instal·lada en una VM a un servei gestionat, i el criteri per saber quan l'IaaS continua estant justificat. Coneixes el catàleg complet de serveis de dades d'Azure com una taula de decisió, amb el cas típic de cadascun i, encara més útil, el cas en què cal descartar-lo.

També tens els sis criteris amb què defensar una tria davant d'un comitè —model, consistència davant de latència, volum, patró d'accés, compatibilitat i equip—, una lectura pràctica del teorema CAP aplicada a dues dades reals de l'aerolínia amb respostes oposades, i les quatre dimensions per les quals factura qualsevol base de dades gestionada, amb la distinció entre aprovisionat i sense servidor que elimina de cop el 73 % de la despesa de l'entorn de desenvolupament. I sobretot tens el mapa de dades de Contoso: cinc sistemes, cinc magatzems, una justificació escrita per a cadascun.

Aquest mapa és el guió de les properes cinc lliçons, i comencem pel cor del negoci. A la lliçó següent, Azure SQL Database, desplegaràs per fi el servidor lògic sql-contoso-reservas-pro i la base db-reservas: triaràs entre models de compra DTU i vCore, entendràs per què el «servidor» no és una màquina, crearàs l'esquema de vols, passatgers i reserves amb els seus índexs raonats, i connectaràs la base a snet-datos mitjançant el punt de connexió privat pe-sql-reservas amb l'accés públic deshabilitat, tancant el forat que vas deixar obert al mòdul 2. I veuràs com recuperar les dades quan algú executa una migració mal preparada un dimarts a la tarda.