Serviços e Arquitectura na Nuvem

Proposta pedagógica — por validar pela Ologa/ATDI. Este conteúdo é um rascunho preparado pela equipa. A sua disponibilidade na plataforma não significa aprovação nem validação técnica.

Duração prevista: 110 minutos, em sessão presencial.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 35 minutos.
• Actividade prática: 55 minutos.
• Partilha e síntese: 10 minutos.

Objectivos da lição

• Distinguir uma base de dados instalada numa máquina virtual de uma base de dados gerida pelo fornecedor, indicando o que muda em responsabilidade e em trabalho.
• Explicar o que a plataforma como serviço assume por nós e o que continua do nosso lado.
• Publicar uma aplicação simples numa plataforma como serviço, no ambiente de formação, verificando o resultado e apagando o que foi criado.

Explicação

Uma base de dados pode correr de duas maneiras na nuvem. Instalada por nós numa máquina virtual, damos-lhe a versão que quisermos e mandamos em tudo — e ficamos com as actualizações, as cópias de segurança, a alta disponibilidade e a afinação a nosso cargo. Gerida pelo fornecedor, recebemos um ponto de ligação e o fornecedor trata do sistema operativo, das actualizações do motor, das cópias automáticas e, se for contratado, da réplica noutra zona. Continua a ser nossa a modelação dos dados, o desempenho das consultas, quem tem acesso e o cumprimento das regras de protecção de dados.

A escolha entre relacional e não relacional mantém-se igual à de sempre: dados com estrutura estável e necessidade de consistência forte — processos, licenças, pagamentos — pedem base relacional; dados de forma variável e volume grande — registos de eventos, documentos, leituras de sensores — encaixam melhor em bases não relacionais. Na nuvem os dois tipos existem em versão gerida.

A plataforma como serviço aplica a mesma ideia à aplicação. Entrega-se o código e a plataforma trata do servidor, do sistema operativo, do servidor de aplicação e do certificado de segurança do endereço, além de permitir aumentar o número de instâncias quando a procura sobe. Do nosso lado ficam o código, a configuração da aplicação, os segredos — que não vão no código, mas na configuração do serviço ou num cofre de segredos — e as ligações à base de dados. Para equipas pequenas costuma dar mais resultado por menos trabalho, e por isso interessa a serviços públicos com poucas pessoas na área informática — mas não é vantajoso em todos os casos: depende dos limites da plataforma e do plano contratado.

As limitações também se devem conhecer. A plataforma impõe versões de linguagem suportadas, tempos máximos de resposta, e por vezes não permite instalar componentes de sistema. Uma aplicação antiga pode não caber sem alterações. É aí que entra a modernização: dividir a aplicação em partes independentes, os microserviços, trocar componentes locais por serviços geridos, e adoptar práticas de integração e entrega contínuas, em que cada alteração é construída e publicada por um processo automático e repetível. Modernizar tem custo e risco, e faz-se por etapas — nunca é obrigatório modernizar tudo para começar a usar nuvem.

Uma nota sobre custos que vale para todo o módulo: o custo depende do plano contratado e há planos em que a capacidade fica reservada, consumindo mesmo com pouco tráfego. Verifica-se antes, no plano concreto, em vez de assumir. Nada é prometido como gratuito e, no laboratório, o que se cria é apagado no fim.

A consulta pública de estado do processo, em Ondela (cenário fictício)

Ondela quer uma página onde o munícipe introduz o número do processo e vê o estado: recebido, em análise, deferido ou indeferido. Não há dados pessoais na resposta, apenas o estado.

A equipa decide publicar essa página numa plataforma como serviço, ligada a uma base de dados gerida onde os estados são actualizados pelo sistema interno. O sistema interno, mais antigo, continua onde está: não é preciso modernizar tudo para pôr esta consulta no ar.

Ficam definidos três pontos antes de avançar: quem pode alterar os estados, quanto tempo ficam guardados os registos de acesso e o que acontece à consulta quando a ligação do distrito cai. Cenário fictício, para exercício.

Actividade prática

Trabalho nos mesmos pares, um computador por par e alternância de quem executa; havendo equipamento, um computador por pessoa, conforme o máximo de dois formandos por computador fixado no Termo de Referência, com 55 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.

Primeira parte, em papel, 10 minutos: para a consulta de estado de Ondela, escrevam o que fica do lado do fornecedor e o que fica do lado da instituição, em duas colunas, incluindo segredos, cópias de segurança e controlo de acesso.

Segunda parte, no ambiente de formação, 45 minutos: executar o laboratório de publicação de uma aplicação simples numa plataforma como serviço, trocando de executante a meio.

Terceira parte, dentro do tempo de laboratório: apagar o que foi criado, pela ordem de dependências, e registar a eliminação.

Produto esperado: tabela de responsabilidades partilhadas e evidência da aplicação a responder e depois eliminada, com o endereço público, as horas e o registo de quem executou cada metade.

Laboratório — Publicar uma aplicação simples numa plataforma como serviço

Laboratório por executar. Este guião ainda não foi executado por nós. O ambiente de formação está por preparar: a conta institucional de formação, os limites de consumo e as permissões são definidos pelo formador antes da sessão. Nunca se usam dados reais de pessoas, nunca se escrevem credenciais no material e nada é adquirido durante a aula. A leitura deste guião é preparação; não substitui a prática no ambiente real.

Percurso didáctico: Azure App Service, em Linux, com a aplicação Node.js mínima fornecida com este curso. Método único de publicação: linha de comandos do Azure, com implantação a partir de ficheiro comprimido. O fornecedor é exemplo de ensino, escolhido pela clareza da documentação, e não uma imposição do Termo de Referência nem uma recomendação de compra.

Pré-requisitos

• Conta institucional de formação com limites de consumo e alertas definidos pelo formador, e grupo de recursos do exercício criado.
• Microsoft Azure — subscrição institucional de formação e grupo de recursos do exercício, com utilizador de formação limitado a esse grupo de recursos. Nada é necessário do lado da Amazon nesta lição.
• Aplicação de exemplo já disponível nesta plataforma, para descarregar: os ficheiros index.js e package.json estão em /exemplos/paas-node/index.js e /exemplos/paas-node/package.json. Usam apenas o módulo http do Node.js, sem dependências a instalar, sem base de dados, sem dados de pessoas e sem segredos no código. O código completo está transcrito mais abaixo.
• Linha de comandos do Azure instalada e sessão iniciada com a conta institucional de formação, feita pelo formador antes da sessão. Não se usam tokens, nem credenciais de publicação, nem autenticação básica.
• Programa para criar ficheiros comprimidos, disponível no sistema operativo da sala.
• Nenhum participante associa cartão de pagamento nem cria subscrição própria. O escalão de serviço a usar é o indicado pelo formador; o material não promete gratuitidade.
• Se a turma não tiver ambiente de desenvolvimento, o formador disponibiliza o código já preparado num arquivo, para carregamento directo.

Ficheiros do exemplo

O exemplo está completo aqui e também disponível para descarregar. Não tem dependências a instalar.

index.js — descarregar

// Exemplo mínimo para o laboratório de plataforma como serviço.
// Proposta pedagógica — por validar pela Ologa/ATDI. Sem dependências externas.
// Usa apenas o módulo http do Node.js.

const http = require("http");

const port = process.env.PORT || 8080;
const mensagem = process.env.MENSAGEM_EXEMPLO || "Mensagem por definir na configuração do serviço.";

const servidor = http.createServer((pedido, resposta) => {
  // Registo mínimo: apenas o método HTTP. Não regista o caminho nem os
  // parâmetros do endereço, que podem conter dados pessoais; não regista
  // cabeçalhos, corpo, endereços nem qualquer dado que possa identificar
  // uma pessoa.
  console.log(pedido.method);

  resposta.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
  resposta.end(
    "Laboratório de plataforma como serviço — exemplo de formação.\n" +
      `Mensagem configurada: ${mensagem}\n`,
  );
});

// Escuta em todas as interfaces: exigido pela plataforma.
servidor.listen(port, "0.0.0.0", () => {
  console.log(`Servidor de exemplo à escuta na porta ${port}`);
});

package.json — descarregar

{
  "name": "exemplo-paas-formacao",
  "version": "1.0.0",
  "private": true,
  "description": "Exemplo mínimo de aplicação Node.js para o laboratório de plataforma como serviço do curso Computação em Nuvem.",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "engines": {
    "node": ">=20"
  },
  "dependencies": {}
}

Passos

1. Teste local, antes de qualquer publicação: descarregar os dois ficheiros do exemplo, colocá-los numa pasta e executar «node index.js». Abrir http://localhost:8080 e confirmar a resposta. Parar, executar de novo definindo a variável MENSAGEM_EXEMPLO e confirmar que o texto muda. Este teste é local e não usa nuvem nenhuma; serve para separar problemas do código de problemas da publicação.
2. No portal do Azure, dentro do grupo de recursos do exercício, criar uma aplicação Web indicando pilha de execução Node.js e sistema operativo Linux, com nome que identifique a turma e o grupo.
3. Escolher o plano de serviço indicado pelo formador e a região combinada. Não subir de escalão por iniciativa própria.
4. Rever e criar. Esperar pela conclusão e abrir a página do recurso.
5. Preparar o ficheiro comprimido: colocar index.js e package.json numa pasta vazia e comprimir os DOIS ficheiros de forma a ficarem na raiz do arquivo, e não dentro de uma subpasta. Verificar a listagem do arquivo antes de publicar.
6. Publicar com um único comando, a partir da pasta onde está o arquivo: az webapp deploy --resource-group <grupo-de-recursos> --name <nome-da-aplicacao> --src-path exemplo-paas.zip --type zip
7. Confirmar nas definições gerais da aplicação que a versão de Node.js corresponde à indicada no package.json e que o comando de arranque é «node index.js». O arquivo publicado não é construído automaticamente, por isso a aplicação tem de correr tal como está — é por essa razão que o exemplo não tem dependências a instalar.
8. Abrir o endereço público atribuído à aplicação e confirmar que a página responde.
9. Nas definições da aplicação, criar a variável de configuração MENSAGEM_EXEMPLO com um valor fictício, guardar, aguardar o reinício e recarregar a página: o texto apresentado muda. A variável não é segredo, mas demonstra o mecanismo — é assim que se tratam também as palavras-passe, fora do código.
10. Confirmar nos registos da aplicação que o pedido feito no navegador aparece registado.
11. Registar na ficha o endereço público, a hora da publicação e o escalão usado.
12. Limpeza: apagar a aplicação Web. Quanto ao plano de serviço, apagar apenas se tiver sido criado para este exercício; se for partilhado ou já existisse, NÃO se apaga e regista-se na ficha. O plano continua a consumir mesmo sem aplicação, por isso o formador confirma no fim que não ficou nenhum plano exclusivo esquecido.

Como verificar o resultado

• O endereço público da aplicação abre no navegador e mostra a página de exemplo.
• A variável de configuração definida no portal é visível no comportamento da aplicação, sem constar do código.
• Os registos mostram o pedido correspondente ao acesso feito.
• Depois da limpeza, o endereço deixa de responder e o grupo de recursos do exercício fica apenas com os recursos partilhados que já lá estavam antes da sessão, se existirem.

Problemas comuns

• Nome de aplicação já usado: o endereço é único; acrescentar o código da turma e do grupo.
• A página mostra erro de aplicação: quase sempre falta o ficheiro de arranque esperado ou a pilha de execução escolhida não corresponde ao código; verificar os registos antes de repetir a publicação.
• Publicação concluída mas página antiga: aguardar o reinício da aplicação ou forçá-lo; não publicar várias vezes seguidas às cegas.
• Escalão indisponível na região: escolher outra região da lista autorizada, mantendo o mesmo escalão.
• Plano de serviço esquecido depois de apagar a aplicação: é um recurso separado; se foi criado só para este exercício, apaga-se também.
• Comando recusado por falta de sessão: a sessão da linha de comandos é iniciada pelo formador com a conta institucional; os participantes não introduzem credenciais próprias.
• Arquivo com uma pasta a envolver os ficheiros: a aplicação não arranca; recriar o arquivo com index.js e package.json na raiz.

Evidência a recolher

A evidência não pode conter segredos: sem chaves, sem palavras-passe, sem tokens, sem dados pessoais. Tapar identificadores de subscrição nas imagens.

• Captura de ecrã da execução local do exemplo, antes de qualquer publicação.
• Captura de ecrã da página publicada, com o endereço visível.
• Captura de ecrã das definições de configuração mostrando a variável de exemplo, com valores fictícios apenas.
• Captura de ecrã da lista de recursos depois da limpeza, mostrando que a aplicação já não consta; se o plano de serviço era exclusivo do exercício, a captura mostra também que ele já não consta.
• Linha na ficha com endereço, escalão, hora de publicação e hora de eliminação.

Limpeza

• Apagar por ordem de dependências, apenas no Azure e apenas os recursos deste exercício: primeiro a aplicação Web, que depende do plano de serviço.
• Apagar o plano de serviço apenas se tiver sido criado para este exercício. Se o plano for partilhado com outros grupos ou já existisse, NÃO se apaga; regista-se na ficha que ficou por ser partilhado.
• Conferir que no grupo de recursos do exercício ficaram apenas os recursos partilhados anteriores à sessão, e registar o que foi apagado.

Apagar apenas os recursos criados neste exercício, dentro do grupo de recursos do exercício. Não apagar nada fora dele.

Síntese em leitura fácil

• Base de dados gerida: o fornecedor trata do motor e das cópias; nós tratamos dos dados, dos acessos e das consultas.
• Plataforma como serviço: entregamos código, a plataforma trata do servidor e do certificado do endereço.
• Os segredos ficam na configuração do serviço ou num cofre, nunca no código.
• A plataforma impõe limites, como versões suportadas; aplicações antigas podem precisar de alterações.
• Modernizar — microserviços, serviços geridos, entrega automática — faz-se por etapas e não é condição para começar.
• Conforme o plano, a capacidade pode ficar reservada e consumir mesmo sem tráfego: verifica-se antes, e no exercício apaga-se o que foi criado, incluindo o plano se tiver sido criado para o exercício.

Verificação formativa

Estas perguntas não contam para a nota final e não são perguntas do exame final. Servem para a pessoa formanda confirmar o que percebeu.

1. Com uma base de dados gerida, deixamos de ser responsáveis pela protecção dos dados pessoais que lá estão?
2. Onde deve ficar a palavra-passe de ligação à base de dados numa aplicação publicada em plataforma como serviço?

Respostas comentadas da verificação formativa

As respostas abaixo pertencem às perguntas de verificação formativa desta lição. Não são perguntas nem respostas do exame final e não têm qualquer efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. Com uma base de dados gerida, deixamos de ser responsáveis pela protecção dos dados pessoais que lá estão?

Resposta: Não. O fornecedor trata da infra-estrutura e do motor; a instituição continua responsável pelos dados, por quem lhes acede e pelo cumprimento das regras aplicáveis.

Comentário: Esta é a linha de responsabilidade partilhada que já apareceu no módulo 1 e que volta no módulo sobre protecção de dados.

Pergunta 2. Onde deve ficar a palavra-passe de ligação à base de dados numa aplicação publicada em plataforma como serviço?

Resposta: Na configuração do serviço ou num cofre de segredos, nunca escrita no código nem no material de formação.

Comentário: Segredos no código acabam quase sempre em repositórios partilhados, e a partir daí deixam de ser segredos.

Referências consultadas

• Azure App Service — Quickstart: criar uma aplicação Web Node.js — https://learn.microsoft.com/en-us/azure/app-service/quickstart-nodejs (consultado em 21 de Setembro de 2026).
• Azure App Service — Implantar ficheiros comprimidos (nota: o envio pela interface Kudu não funciona em Linux e o arquivo não é construído por defeito) — https://learn.microsoft.com/en-us/azure/app-service/deploy-zip (consultado em 21 de Setembro de 2026).