Azure Básico — Servicios Core para Desarrolladores

Overview

Un equipo con el que trabajé migró un monolito .NET a Azure en un fin de semana: App Service para la capa web, Azure SQL para la base de datos, Blob Storage para los archivos subidos, y Managed Identity en lugar de contraseñas en las cadenas de conexión. Ni un servidor que parchear, ni una credencial en un archivo de configuración, y todo corrió en el free tier durante el primer mes. Ese stack (cómputo, almacenamiento, una base de datos, un perímetro de red y un modelo de identidad) es lo que cubre esta guía.

Azure es la segunda plataforma cloud más grande y la opción por defecto en organizaciones que ya pagan por Microsoft 365, Active Directory y licencias de Visual Studio. Si escribes .NET, es el cloud más sencillo al que desplegar; si escribes cualquier otra cosa, el tooling sigue siendo sólido. La CLI az, los SDKs de Python/Node y la integración con GitHub Actions funcionan sin tocar una máquina Windows. Esta guía recorre los servicios que de verdad usarás en una aplicación típica, cómo elegir entre ellos y los errores que le cuestan dinero de verdad a los equipos en su primer trimestre.

Cuándo Usar Azure

Elige Azure cuando:

• Tu organización ya funciona con Microsoft: aplicaciones .NET, Office 365, Active Directory, licencias de Windows Server reutilizables mediante Azure Hybrid Benefit
• Necesitas cloud híbrido: ExpressRoute y Azure Arc conectan datacenters on-premises mejor que cualquier equivalente de la competencia
• Quieres CI/CD integrado: Azure DevOps viene incorporado, y GitHub Actions (también de Microsoft) tiene acciones de despliegue a Azure de primer nivel
• Construyes aplicaciones empresariales donde la identidad importa: Entra ID es el sistema de single sign-on y acceso condicional más potente de cualquier cloud

Si tu equipo ya trabaja con AWS o tus cargas de trabajo son pipelines de datos sobre Kubernetes, compara antes con la guía básica de AWS. Los servicios se mapean casi uno a uno, y la decisión suele saldarse con los contratos y las habilidades que ya tienes.

Configurar tu Entorno

Crea primero una cuenta gratuita. Obtienes 200 USD de crédito para 30 días más 12 meses de cuotas gratuitas (750 horas de VMs B1s, 5 GB de Blob Storage, 1 millón de ejecuciones de Functions al mes). Luego instala la CLI de Azure:

# Instalar (Windows: winget install Microsoft.AzureCLI; macOS: brew install azure-cli)
az login

# Fija la suscripción con la que vas a trabajar
az account list --output table
az account set --subscription "My Subscription"

# Todo en Azure vive dentro de un resource group — crea uno por entorno
az group create --name rg-myapp-dev --location eastus

Un resource group es un límite de ciclo de vida: todo lo que hay dentro se despliega, se factura y se borra junto. Borra el grupo y cada recurso que contiene desaparece. Eso convierte a los resource groups en tu mejor aliado para levantar entornos de prueba y derribarlos sin costes huérfanos. Etiquétalos pronto (env:dev, team:payments) o tus informes de costes se convertirán en preguntas sin respuesta. Un script de bootstrap que aprovisiona todo el entorno de desarrollo de esta sección está en los recursos companion.

Cómputo — Elegir el Servicio Correcto

Azure te da cinco formas de ejecutar código, y elegir mal es el error más caro del principiante. La escalera de más control a menos gestión tiene esta pinta:

Servicio	Modelo	Úsalo para	Evítalo cuando
Virtual Machines	IaaS	Apps legacy, configuración de SO a medida, lift-and-shift	Quieres que la plataforma parchee y escale por ti
App Service	PaaS	Web apps, APIs REST, backends en .NET/Java/Node/Python/PHP	Cargas irregulares que pasan el tiempo ociosas (pagas el plan, no las peticiones)
Azure Functions	Serverless	Manejadores de eventos, jobs programados, webhooks, procesamiento de archivos	Trabajo de más de ~10 min en Consumption, o volumen alto constante (Premium se encarece)
Container Apps	Contenedores gestionados	Microservicios, apps con Dapr, contenedores con scale-to-zero	Necesitas control total de la API de Kubernetes
AKS	Kubernetes gestionado	Flotas grandes de microservicios, orquestación compleja	Equipos pequeños — el impuesto operativo es real

Azure Virtual Machines

Control total del SO. Tú gestionas parches, escalado y salud. Reserva las VMs para software que no puede correr en un servicio de plataforma.

# Crear una VM con la CLI de Azure
az vm create \
  --resource-group rg-myapp-dev \
  --name myVM \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys

Serie de VM	Caso de uso
B-series	Burstable — acumula créditos de CPU en reposo; barata para dev/test
D-series	Cargas de producción de propósito general
F-series	Optimizada para cómputo, alta ratio CPU/memoria
E-series	Optimizada para memoria — cachés, bases de datos en memoria

La serie B sorprende a mucha gente: es barata porque acumula créditos de CPU mientras está ociosa y los gasta cuando trabaja. Un agente de CI que compila todo el día agota los créditos y se estrangula al rendimiento base. Revisa la métrica CPU Credits Remaining antes de culpar al código.

App Service

El caballo de batalla para cargas web: empujas código o un contenedor, y Azure gestiona el SO, el escalado, el TLS y los deployment slots.

# Crear un plan y una web app
az appservice plan create --name plan-myapp --resource-group rg-myapp-dev --sku B1 --is-linux
az webapp create \
  --resource-group rg-myapp-dev \
  --plan plan-myapp \
  --name my-webapp-123 \
  --runtime "NODE|18-lts"

Los deployment slots son la característica que lo vende: despliegas a un slot staging, lo calientas, y haces az webapp deployment slot swap para intercambiarlo con producción. Si el swap rompe algo, intercambias de vuelta. La versión anterior sigue corriendo. Es un despliegue blue-green integrado en la plataforma, sin scripting.

Azure Functions

Código dirigido por eventos que factura por ejecución: el primer millón de ejecuciones mensuales es gratis en el plan Consumption.

[FunctionName("HttpTrigger")]
public static IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req)
{
    return new OkObjectResult("Hello from Azure Functions");
}

Dos realidades operativas que conviene saber antes de adoptar Functions. Primero, el cold start: en Consumption, una función ociosa durante ~20 minutos tarda segundos en despertar. Inaceptable para latencia de cara al usuario, perfecto para trabajos en segundo plano. Segundo, los triggers son el quid: una Function que solo responde a HTTP suele estar mejor en App Service; Functions justifica su complejidad cuando reacciona a colas, blobs, timers o Event Grid.

Almacenamiento — Blob, Queue y Table

Una storage account aloja cuatro servicios. Blob se lleva la atención, pero Queue y Table mueven en silencio la mitad de la mayoría de arquitecturas Azure.

Blob Storage

Almacenamiento de objetos para datos no estructurados: uploads, imágenes, backups, logs, assets estáticos.

# Crear una storage account y un container
az storage account create --name mystorage123 --sku Standard_LRS --resource-group rg-myapp-dev
az storage container create --name uploads --account-name mystorage123

# Subir un archivo
az storage blob upload --container-name uploads --file report.pdf --name report.pdf

Tier	Caso de uso	Trampa
Hot	Datos accedidos con frecuencia	Precio de almacenamiento más alto, acceso más barato
Cool	Datos almacenados ≥ 30 días, acceso raro	Penalización por borrado anticipado si sacas datos antes de 30 días
Cold	Datos almacenados ≥ 90 días	Misma penalización, ventana más larga
Archive	Archivos de cumplimiento, ≥ 180 días	La recuperación tarda horas — es un trabajo de rehidratación, no una lectura

El tier Archive parece gratis hasta que alguien restaura un backup desde ahí durante un incidente y espera tres horas la rehidratación. Para el desglose completo de patrones de acceso, reglas de ciclo de vida e integración con CDN, consulta la guía de Blob Storage.

Queue Storage

Una cola de mensajes sencillísima para desacoplar componentes: más barata y simple que Service Bus, y suficiente para la mayoría de trabajos “procesa esto luego”.

from azure.storage.queue import QueueServiceClient

queue = QueueServiceClient.from_connection_string(conn_str).get_queue_client("tasks")
queue.send_message("process-order-123")
message = queue.receive_message()

receive_message no borra el mensaje; lo oculta durante un visibility timeout. Tu consumidor debe llamar a delete_message tras procesarlo, o el mensaje reaparece y se procesa dos veces. Diseña consumidores idempotentes; la entrega at-least-once convierte los duplicados en un evento normal, no en un caso límite.

Bases de Datos — Azure SQL y Cosmos DB

Azure SQL

SQL Server gestionado con backups, parches y alta disponibilidad resueltos por ti.

# Crear un servidor y una base de datos — mantén la contraseña fuera del comando
az sql server create --name myserver \
  --admin-user sqladmin \
  --admin-password "$SQL_ADMIN_PASSWORD"
az sql db create --server myserver --name mydb --service-objective S0

Los tiers tipo DTU/S0 valen para aprender, pero revisa el serverless compute tier para bases de datos de desarrollo: se auto-pausa cuando está ociosa y factura por segundo de uso real, lo que convierte una base de datos de desarrollo que pasa la noche dormida en algo casi gratis.

Cosmos DB

NoSQL distribuido globalmente con latencia de lectura de milisegundos de un dígito garantizada: el servicio al que recurres cuando el modelo relacional o el despliegue regional de Azure SQL se convierte en el cuello de botella.

from azure.cosmos import CosmosClient

client = CosmosClient(url, credential=key)
database = client.create_database_if_not_exists("mydb")
container = database.create_container_if_not_exists("users", partition_key="/id")
container.upsert_item({"id": "user-1", "name": "Alice"})

La elección del partition_key es la decisión que persigue a los usuarios de Cosmos DB: cada consulta que filtra por otra propiedad se abanica por todas las particiones (una “cross-partition query”) y multiplica tu factura de request units. Elige una clave que coincida con tu filtro de consulta más común (/id para lookups por usuario, /tenantId para apps multi-tenant) y diseña el modelo de datos alrededor de ella, no al revés. El free tier te da 1,000 RU/s y 25 GB para siempre, suficiente para aprender.

Redes — Virtual Networks

Una Virtual Network (VNet) aísla tus recursos en un espacio de direcciones privado. Todo lo que Azure despliega en una VNet obtiene una IP privada; nada es alcanzable desde internet salvo que lo expongas deliberadamente.

VNet 10.0.0.0/16
├── Subnet A (pública)  10.0.1.0/24 — integración App Service, inbound público
└── Subnet B (privada) 10.0.2.0/24 — VMs, Private Endpoints, sin inbound

Los servicios que más importan:

• Private Endpoint / Private Link — coloca un servicio PaaS (SQL, Blob, Key Vault) en una IP privada dentro de tu VNet. Así es como una base de datos deja de ser alcanzable desde internet por completo, y es la medida de seguridad con más impacto de esta guía.
• VNet Peering — conecta dos VNets entre regiones o suscripciones con tráfico privado.
• Network Security Groups — las reglas de firewall asociadas a las subredes; deny-by-default en inbound es la línea base sensata.
• Application Gateway — load balancer de capa 7 con Web Application Firewall integrado.
• Azure Firewall — protección gestionada a nivel de red para el tráfico saliente.

El patrón que muerde a todo el mundo: un desarrollador crea un servidor Azure SQL, marca “Allow Azure services and resources to access this server” para que su app funcione, y deja sin querer la base de datos abierta a todos los clientes de Azure — no solo a sus propios recursos. Usa Private Endpoint en su lugar, o como mínimo bloquea el firewall a tus IPs de salida.

Identidad — Microsoft Entra ID

Azure Active Directory (renombrado Microsoft Entra ID en 2023) gestiona autenticación y autorización. Para desarrolladores, dos conceptos importan más que el resto:

Managed Identity le da a tu app una identidad sin credenciales. Un App Service con managed identity asignada por el sistema puede llamar a Key Vault, Storage o SQL con cero secretos en la configuración: Azure gestiona el ciclo de vida del token, la rotación y la revocación. Lo activas una vez y eliminas toda una categoría de incidentes de “cadena de conexión filtrada”:

az webapp identity assign --name my-webapp-123 --resource-group rg-myapp-dev

RBAC controla quién puede hacer qué. Los roles son gruesos (Owner, Contributor, Reader) más cientos de estrechos. Concede a nivel de resource group, prefiere roles estrechos, y nunca des a un service principal de CI/CD Contributor sobre toda la suscripción cuando Website Contributor en un resource group hace el trabajo.

Un token de acceso de Entra decodificado lleva la identidad y los roles de tu app registration:

{
  "issuer": "https://login.microsoftonline.com/{tenant}/v2.0",
  "audience": "{client-id}",
  "claims": {
    "roles": ["Reader", "Contributor"]
  }
}

Para CI/CD, prefiere la federación OIDC sobre secretos almacenados: GitHub Actions puede autenticarse contra Azure con una credencial federada. Sin un secreto AZURE_CREDENTIALS caducando en una bóveda que olvidaste.

Key Vault — Gestión de Secretos

Cada clave, certificado y cadena de conexión que tu app necesita pertenece a Key Vault, referenciado por nombre; nunca en appsettings.json, archivos de entorno o variables de pipeline que cualquiera pueda imprimir.

az keyvault create --name kv-myapp-123 --resource-group rg-myapp-dev --location eastus
az keyvault secret set --vault-name kv-myapp-123 --name "DbPassword" --value "$SQL_ADMIN_PASSWORD"

La combinación que hace esto seguro en la práctica: Managed Identity en el lado de la app, Key Vault en el lado del secreto, y una asignación RBAC (Key Vault Secrets User) conectándolos. La app pide DbPassword a Key Vault al arrancar usando su managed identity: ningún humano lee el valor, y rotarlo está a un secret set de distancia. Activa soft-delete y purge protection antes de guardar nada real; los secretos borrados son recuperables durante 90 días, lo que ha salvado más de un az keyvault secret delete escrito con el dedo gordo.

Monitorización — Azure Monitor y Application Insights

Azure Monitor es la capa de telemetría de toda la plataforma: métricas, logs y alertas para cada recurso. Application Insights es la pieza a nivel de aplicación dentro de él: trazado de peticiones, llamadas a dependencias, excepciones y métricas en vivo de tu código.

az monitor app-insights component create \
  --app myapp-insights \
  --resource-group rg-myapp-dev \
  --location eastus

La parte que la mayoría de equipos se salta es KQL: el lenguaje de consulta de Log Analytics, donde aterriza cada log de diagnóstico. Aprender cinco operadores de KQL (where, summarize, order by, project, render) convierte “la app va lenta” en “la latencia p95 se duplicó en el endpoint /checkout a las 14:03, correlacionado con un despliegue”. Configura alertas con action groups sobre las señales que duelen (tasa de HTTP 5xx, dependencias fallidas, uso de cuotas) antes del lanzamiento, no después del primer incidente.

Errores Comunes

• Desplegar todo en una sola región. Una caída regional tumba toda tu app. Como mínimo conoce tu historia de DR, y usa availability zones para todo lo que importe.
• Dejar service principals con client secrets. Los secretos caducan y se filtran; Managed Identity o la federación OIDC eliminan el problema entero.
• Crear recursos sin controles de coste. Una VM olvidada o un plan Always-On de App Service quema dinero en silencio. Pon una alerta de presupuesto en Cost Management el primer día.
• Sobreaprovisionar cómputo. Elegir por defecto un plan P-series de App Service o una VM D-series para un entorno de desarrollo; las series B y los tiers serverless existen por algo. Revisa las recomendaciones de Azure Advisor cada mes.
• “Allow Azure services” en bases de datos. Esa casilla abre tu servidor SQL a todos los tenants de Azure, no solo a tu app. Usa Private Endpoint.
• Tratar el tier Archive como backups baratos. La rehidratación tarda horas. Un “backup” en Archive que no puedes restaurar durante un incidente no es un backup.

Troubleshooting

• az deployment falla con quota exceeded. Las suscripciones nuevas arrancan con cuotas regionales de vCPU bajas (a menudo 4-10 núcleos). Comprueba az vm list-usage --location eastus y abre un ticket de soporte de aumento de cuota: son gratis y suelen aprobarse en horas.
• La Function va lenta en la primera petición tras estar ociosa. Cold start del plan Consumption. O lo aceptas para trabajo en segundo plano, o mantienes la función caliente con un timer trigger, o mueves las funciones sensibles a latencia a un plan Premium.
• App Service despliega pero devuelve 503 / “application error”. Consigue la excepción real: az webapp log tail o la hoja Log stream. Nueve de cada diez veces es una cadena de conexión o un app setting que existe en local pero nunca se desplegó. Compara con az webapp config appsettings list.
• El swap a producción funcionó y luego todo 404. Los settings específicos del slot no se movieron. Marca como “deployment slot settings” todo lo que deba quedarse anclado a un slot.
• Las facturas de Cosmos DB son más altas de lo esperado. Estás ejecutando cross-partition queries. Revisa Query Metrics en Insights: si Retrieved Document Count ≫ Returned Document Count, tu partition key no coincide con tus patrones de consulta.
• DefaultAzureCredential falla en local pero funciona en Azure. En local recurre a tus credenciales de az login. Ejecuta az login en el terminal donde corre tu app, y comprueba que tu cuenta tiene el mismo rol RBAC que tiene la managed identity en el cloud.

See Also

• Guía de Buenas Prácticas de Terraform — define esta infraestructura como código en lugar de hacer clic por el portal
• Guía Avanzada de Kubernetes — cuando te quedas corto con App Service y necesitas AKS
• AWS Básico — Servicios Core para Desarrolladores — los mismos servicios en el cloud competidor
• Guía de Blob Storage — tiers de acceso, políticas de ciclo de vida e integración con CDN en profundidad
• Microsoft Learn — Fundamentos de Azure
• Azure Architecture Center — arquitecturas de referencia para los patrones de esta guía
• FAQ de la Cuenta Gratuita de Azure — cuotas y límites actuales del free tier

Código companion: recursos de Azure básico — el script azure-bootstrap.sh que aprovisiona el entorno de desarrollo usado a lo largo de esta guía.