A la lliçó anterior vam conèixer què és Azure i qui és Contoso Airlines. Ara toca respondre a les dues preguntes que condicionen qualsevol disseny posterior: quanta responsabilitat vull continuar tenint? i on viurà físicament la meva plataforma?

La primera pregunta es respon amb els models de servei (IaaS, PaaS, SaaS i serverless) i amb el model de responsabilitat compartida. La segona, amb la jerarquia geogràfica d'Azure: geografies, regions, parells de regions i zones de disponibilitat. Totes dues decisions són difícils de desfer més endavant —canviar de regió un sistema en producció és un projecte, no un ajust—, així que val la pena entendre-les bé abans de crear el primer recurs.

1. Els models de servei i l'analogia del control
2. Comparativa: qui gestiona què
3. Serverless: el cas especial
4. El model de responsabilitat compartida
5. Geografies, regions i parells de regions
6. Zones de disponibilitat i conjunts de disponibilitat
7. Com triar regió
8. SLA i la seva relació amb la redundància
9. La decisió de Contoso Airlines
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió

L'analogia més útil per entendre els models de servei és com arribes a la teva destinació quan viatges. En tots els casos hi arribes; el que canvia és quanta feina fas tu i quant control conserves.

Traduït a informàtica:

Azure t'entrega la infraestructura virtualitzada: màquines virtuals, discos, xarxes. Tu instal·les el sistema operatiu (o tries una imatge), l'apedaces, instal·les el programari, el configures i el mantens.

• Exemples a Azure: Màquines Virtuals, Discos administrats, Xarxes virtuals.
• Quan fer-lo servir: migracions ràpides de sistemes existents, programari que exigeix control del sistema operatiu, càrregues heretades.
• A Contoso: el motor de disponibilitat heretat, que depèn d'una versió concreta d'una biblioteca, començarà la seva vida a Azure com a màquina virtual (mòdul 2).

Azure t'entrega una plataforma llesta per executar el teu codi o les teves dades. No veus el sistema operatiu ni apedaces res: puges l'aplicació i funciona.

• Exemples a Azure: App Service, Azure SQL Database, Azure Database for PostgreSQL, Azure Container Apps.
• Quan fer-lo servir: aplicacions noves o modernitzables, quan vols dedicar el temps de l'equip al producte i no al manteniment.
• A Contoso: el web Contoso Reserves i l'API de Disponibilitat acabaran a App Service, i la base de dades de reserves a Azure SQL Database (mòduls 2 i 3).

Consumeixes una aplicació acabada per subscripció. No hi ha res per desplegar.

• Exemples: Microsoft 365, Dynamics 365, GitHub. Des del punt de vista de l'usuari, també Azure DevOps.
• A Contoso: el correu corporatiu ja és Microsoft 365; no hi ha cap intenció de gestionar-lo.

Aquesta taula és la referència per a la resta del curs. Marca qui s'ocupa de cada capa. C = client, M = Microsoft.

Fixa't en les dues primeres files: les dades i les identitats són sempre responsabilitat del client, en tots els models. És la idea més important de la lliçó i el motiu pel qual el mòdul 4 existeix.

Serverless ("sense servidor") és un nom desafortunat: servidors n'hi ha, però tu no els veus, no els dimensiones i no pagues quan no es fan servir. És una evolució del PaaS amb dos trets propis:

• Escalat automàtic fins a zero. Si ningú no crida la teva funció, no hi ha instàncies ni hi ha cost de còmput.
• Facturació per execució. Es paga per nombre d'invocacions i per temps d'execució consumit, no per hora de servidor encès.

• Exemples a Azure: Azure Functions, Logic Apps, Event Grid, Azure Container Apps amb escalat a zero.
• A Contoso: la generació del PDF de la targeta d'embarcament després de confirmar una reserva és un cas de manual per a una funció; passa a ràfegues i no justifica un servidor encès les 24 hores. Es construirà al mòdul 6.

Aquest model respon a la pregunta que fa tot responsable de seguretat la primera setmana: "si Microsoft està certificat, de què m'he de preocupar jo?".

La regla general: Microsoft és responsable de la seguretat del núvol; el client és responsable de la seguretat al núvol.

Tres exemples concrets aplicats a Contoso, perquè no quedi en abstracte:

Azure organitza la seva presència física en nivells. De major a menor:

• Geografia: una àrea del món que agrupa regions i que respecta els límits de residència de dades i compliment d'aquell territori (per exemple, Europa). Les dades d'una geografia no en surten llevat que tu ho configuris explícitament.
• Regió: un conjunt de centres de dades dins d'un perímetre de baixa latència, amb un nom comercial (West Europe, North Europe, Spain Central). És la unitat que tries en crear un recurs.
• Parell de regions: cada regió està aparellada amb una altra de la mateixa geografia, situada normalment a més de 300 km, amb dues propietats útils:
  • Alguns serveis repliquen dades automàticament a la regió parella (per exemple, l'emmagatzematge amb redundància geogràfica, que es veu al mòdul 2).
  • En una interrupció àmplia, Microsoft prioritza la recuperació d'una regió del parell i planifica les actualitzacions de plataforma de manera esglaonada, no simultània, per a totes dues.

Exemples de parells a Europa: West Europe (Països Baixos) ↔ North Europe (Irlanda); France Central ↔ France South; Spain Central està aparellada dins de la mateixa geografia europea.

Nota important: Microsoft també està introduint regions no aparellades recolzades en zones de disponibilitat. Comprova sempre a la documentació oficial el parell vigent de la regió que facis servir, perquè el mapa evoluciona.

Aquí és on es decideix de quina errada concreta et protegeixes. Cada nivell cobreix un tipus de desastre diferent i cap no substitueix els altres.

Un conjunt de disponibilitat és un concepte d'IaaS. En col·locar-hi diverses màquines virtuals, Azure les reparteix entre:

• Dominis d'error: grups de servidors que comparteixen alimentació i commutador de xarxa. Distribuir entre dominis d'error evita que una errada elèctrica s'endugui totes les teves VM.
• Dominis d'actualització: grups que Azure reinicia per separat durant el manteniment planificat. Mai no reinicia dos dominis alhora.

Una zona de disponibilitat és un o diversos centres de dades físicament separats dins de la mateixa regió, amb alimentació, refrigeració i xarxa independents, connectats entre si per fibra de molt baixa latència. Les regions habilitades tenen com a mínim tres zones.

Regla pràctica: conjunt de disponibilitat per a IaaS heretada dins d'un centre de dades; zones de disponibilitat quan la regió les ofereix i el servei les admet; parell de regions per al desastre gran.

No hi ha una resposta universal. S'avaluen cinc criteris i es documenta la decisió.

Sobre RGPD i sobirania, tres punts que sovint es confonen:

1. Triar una regió europea manté les dades en repòs dins d'aquella geografia, però determinades metadades i serveis globals (com el mateix directori de Microsoft Entra ID) tenen el seu propi àmbit. Consulta-ho si el teu sector ho exigeix.
2. La replicació geogràfica pot moure dades a la regió parella: comprova que aquesta parella també és dins de la geografia admissible (a Europa, hi és).
3. La responsabilitat de classificar quines dades són personals i aplicar-hi xifratge i retenció és sempre del client, com hem vist a l'apartat 4.

L'SLA (acord de nivell de servei) és el compromís de disponibilitat que Microsoft assumeix per a un servei, amb una compensació econòmica en forma de crèdit si no es compleix. Dos matisos que gairebé ningú no explica:

• El crèdit no cobreix la teva pèrdua de negoci. Si Contoso deixa de vendre bitllets tres hores, el crèdit a la factura no compensa la venda perduda. L'SLA és un senyal de qualitat, no una assegurança.
• L'SLA depèn de com despleguis. No és un número fix del servei: millora si hi afegeixes redundància.

Valors orientatius per a màquines virtuals (consulta sempre les xifres vigents al document oficial d'SLA, perquè s'actualitzen):

I el punt que més sorprèn: quan compons serveis, les disponibilitats es multipliquen. Si el web té 99,95 %, la base de dades 99,99 % i l'emmagatzematge 99,9 %, i la venda necessita tots tres alhora:

És a dir, uns 70 minuts al mes en el pitjor cas, pitjor que qualsevol de les peces per separat. Per això el disseny de disponibilitat es fa sobre el recorregut complet de l'usuari, no servei a servei.

La Marta Ríos documenta així la decisió, que heretarem durant tot el curs:

• Geografia: Europa. Contoso ven a ciutadans de la UE i les seves dades personals no surten de la geografia europea.
• Regió principal: West Europe (Europa Occidental). Motius: té el catàleg de serveis més complet de la geografia, disposa de zones de disponibilitat, i la latència des d'Espanya és de poques desenes de mil·lisegons, acceptable per a la venda.
• Regió secundària: North Europe (Europa del Nord), que és la seva regió parella. Es farà servir per a còpies amb redundància geogràfica i, més endavant, per a la recuperació davant de desastres (mòdul 7).
• Dins de West Europe: els components crítics (web i API) es repartiran entre almenys dues zones de disponibilitat.
• El que Contoso NO fa: no desplega actiu-actiu a les dues regions. Seria el doble de cost i el seu objectiu de recuperació (unes hores) no ho justifica. És una decisió conscient, no un oblit.

• Triar regió per costum o per proximitat aparent. "Com que som a Espanya, faig servir la regió més propera" és un criteri incomplet: pot no tenir el servei que necessites o tenir un altre preu. Avalua els cinc criteris.
• Confondre zones de disponibilitat amb regions. Les zones protegeixen de la caiguda d'un edifici dins de la mateixa regió; no protegeixen d'un desastre regional. I els recursos d'una zona no són accessibles com si fossin en una altra regió.
• Creure que PaaS elimina tota responsabilitat. A PaaS continues sent responsable de les dades, les identitats, la configuració i el codi. Només desapareix el sistema operatiu.
• Pensar que l'SLA garanteix la teva disponibilitat. Només cobreix el servei de Microsoft, i només amb la configuració que hagis desplegat. Un desplegament d'instància única no té l'SLA del desplegament redundant.
• Oblidar que la replicació no és una còpia de seguretat. Si esborres un registre per error, la replicació replica l'esborrat. Necessites còpies amb retenció (mòdul 7).
• Barrejar regions sense motiu. Posar l'aplicació en una regió i la base de dades en una altra afegeix latència a cada consulta i cost de sortida de dades. Mantén junts els components que es parlen molt.
• Consell de cost: si estàs practicant, tot això encara no costa res perquè no hem creat recursos. Però recorda que replicar en diverses zones multiplica les instàncies, i per tant la factura. Cada nivell de disponibilitat té un preu; tria el que el negoci necessita, no el màxim possible.

Per a cada component de la plataforma de Contoso, indica quin model de servei és el més adequat (IaaS, PaaS, serverless o SaaS) i justifica-ho en una frase:

1. El web públic Contoso Reserves, reescrit com a aplicació moderna.
2. El motor de disponibilitat heretat, lligat a una versió concreta d'una biblioteca del sistema.
3. La generació del PDF de la targeta d'embarcament quan es confirma una reserva.
4. El correu corporatiu del personal.
5. La base de dades de reserves, que necessita còpies automàtiques i apedaçament sense intervenció.

Classifica cada incident com a responsabilitat de Microsoft o de Contoso, i explica per què en una frase:

1. Un atac de força bruta aconsegueix entrar amb la contrasenya feble d'un compte administratiu sense autenticació multifactor.
2. Un tall de refrigeració deixa sense servei un centre de dades d'una zona a West Europe.
3. La màquina virtual del motor de disponibilitat fa vuit mesos que no rep actualitzacions de seguretat del sistema operatiu.
4. Una errada de l'emmagatzematge subjacent d'Azure SQL Database provoca 20 minuts d'indisponibilitat.

Contoso vol que la venda de bitllets sobrevisqui a aquests tres escenaris, amb el mínim cost possible en cada cas. Indica quin mecanisme faries servir:

1. Microsoft reinicia l'amfitrió físic on corre la VM durant el manteniment mensual.
2. Un incendi deixa sense servei l'edifici on hi ha una zona de West Europe.
3. Un operador esborra per error tota la taula de reserves de l'últim mes.

A més, calcula la disponibilitat composta d'un recorregut de compra que travessa un balancejador (99,99 %), el web (99,95 %) i la base de dades (99,99 %).

Solució 1:

Solució 2:

1. Contoso. Les identitats i la seva protecció (MFA, polítiques de contrasenya) són sempre del client, en qualsevol model.
2. Microsoft. Infraestructura física del centre de dades. Ara bé, si Contoso va desplegar en una sola zona, la conseqüència sí que és responsabilitat del seu disseny.
3. Contoso. És IaaS: l'apedaçament del sistema operatiu convidat és del client.
4. Microsoft. És PaaS i l'errada és per sota de la capa que gestiona el client; s'aplica l'SLA del servei.

Solució 3:

1. Conjunt de disponibilitat (o, millor, zones si el servei les admet): reparteix les VM en dominis d'actualització diferents perquè el manteniment no les reiniciï alhora. Cost afegit: cap més enllà de tenir més d'una instància.
2. Zones de disponibilitat: instàncies repartides en almenys dues zones de West Europe, darrere d'un balancejador amb redundància de zona.
3. Còpies de seguretat amb retenció i restauració a un punt en el temps. Ni la replicació de zona ni la geogràfica no serveixen aquí: replicarien l'esborrat.

Disponibilitat composta:

Uns 30 minuts d'indisponibilitat al mes, pitjor que qualsevol dels tres components per separat.

Els models de servei descriuen quanta responsabilitat cedeixes: IaaS et deixa el sistema operatiu, PaaS te'l treu, serverless a més et treu la capacitat ociosa i SaaS t'entrega l'aplicació feta. Sigui quin sigui el model, el model de responsabilitat compartida deixa sempre al teu costat les dades, les identitats i la configuració: aquesta és la frase que cal recordar d'aquesta lliçó.

En el pla físic, Azure s'organitza en geografies → regions → zones de disponibilitat, amb parells de regions per al desastre gran i conjunts de disponibilitat per a l'errada de bastidor. Cada nivell protegeix d'un tipus d'errada diferent, té el seu cost i es reflecteix a l'SLA, que a més es multiplica a la baixa quan compons serveis. Contoso Airlines ha decidit West Europe com a regió principal, North Europe com a parella i repartiment en diverses zones per als components crítics.

Amb el "quin model" i el "on" resolts, ja només falta el pràctic: crear el compte. A la lliçó següent, Crear i configurar el teu compte d'Azure, veurem què necessites per registrar-t'hi, què inclou el compte gratuït, quins tipus de subscripció hi ha i —molt important— com posar un pressupost i una alerta de despesa abans de crear el teu primer recurs.