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: 105 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: 50 minutos.
- Partilha e síntese: 10 minutos.
Objectivos da lição
- Desenhar uma arquitectura simples para um serviço público, indicando componentes, fluxos e fronteiras de segurança.
- Justificar, em cada componente, a escolha entre máquina virtual, contentor, execução sem servidor e serviço gerido.
- Identificar onde entram microserviços, práticas cloud-native e entrega automática, e o que fica para uma etapa posterior de modernização.
Explicação
Desenhar uma arquitectura é responder, por escrito, a cinco perguntas: que componentes existem, por onde entra o pedido, onde ficam os dados, que fronteiras de segurança separam as partes e o que acontece quando uma parte falha. Um desenho que não responda a estas cinco perguntas é um diagrama bonito, não uma arquitectura.
A arquitectura mais comum num serviço público simples tem quatro camadas: entrada — o endereço público, com certificado e, se necessário, filtragem de pedidos; aplicação — uma ou mais instâncias, em plataforma como serviço ou em contentores; dados — base de dados gerida numa sub-rede privada, sem endereço público; e armazenamento de objectos, privado, para documentos e digitalizações. Entre camadas, regras de permissão mínima, como se viu na lição de redes.
Microserviços são a divisão da aplicação em partes pequenas e independentes, cada uma com a sua responsabilidade e o seu ritmo de actualização. Resolvem problemas de equipas grandes e de sistemas que crescem; introduzem em troca complexidade de comunicação, de observação e de resolução de problemas. Para um serviço distrital com uma aplicação e duas pessoas na informática, uma aplicação única bem organizada é normalmente a decisão certa, e dividir só quando houver razão concreta.
Cloud-native descreve o estilo de construir para este ambiente: componentes substituíveis, configuração fora do código, estado guardado em serviços próprios e não no disco da máquina, e capacidade de arrancar mais instâncias sem intervenção manual. DevOps é a prática de trabalho que acompanha: mesma equipa responsável por construir e por manter, alterações pequenas e frequentes, e um processo automático que constrói, testa e publica sempre da mesma maneira. O ganho não é a moda: é que a publicação deixa de depender da memória de uma pessoa.
A modernização faz-se por etapas e cada etapa tem de valer por si. Uma sequência frequente: primeiro mover a aplicação como está, depois trocar componentes instalados por serviços geridos, depois automatizar a publicação, e só então, se houver razão, separar partes em serviços independentes. Escrever a ordem das etapas, com o benefício esperado de cada uma, é tão importante como o desenho final — e evita a promessa de que tudo muda ao mesmo tempo.
Por último, o desenho tem de dizer o que fica de fora. Um bom documento de arquitectura tem uma secção de pressupostos e outra de pontos por apurar: ligação disponível no local, volume esperado, exigências de localização dos dados, competências da equipa. Nenhum deles é detalhe técnico — todos podem inverter a decisão.
Arquitectura da consulta de processos de Ondela (cenário fictício)
Entrada: endereço público com certificado, apenas para a página de consulta. Aplicação: uma aplicação única em plataforma como serviço, com duas instâncias. Dados: base de dados gerida em sub-rede privada, sem endereço público, acessível apenas a partir da sub-rede da aplicação. Documentos: armazenamento de objectos privado, com acesso concedido à aplicação e a mais ninguém.
Falhas previstas: se uma instância cair, a outra responde; se a base de dados falhar, a página mostra aviso e o atendimento passa ao procedimento manual; se a ligação do distrito cair, a consulta interna fica indisponível e o balcão usa a listagem impressa do dia.
Etapas de modernização propostas: primeiro publicar a consulta; depois automatizar a publicação; só mais tarde, se o volume crescer, separar a componente de digitalizações. Pressupostos por confirmar: volume diário de consultas e exigências sobre onde os dados podem residir. Cenário fictício, para exercício.
Actividade prática
Trabalho em grupos de quatro, com apresentação por amostra, com 50 minutos de trabalho, seguidos de 10 minutos de partilha e síntese em plenário.
Escolham um dos dois casos fictícios propostos pelo formador, ou o serviço que trabalharam na lição anterior.
Desenhem a arquitectura em papel A3: componentes, setas de fluxo, fronteiras de rede e o que é privado.
Numa folha à parte, justifiquem cada componente — porquê máquina virtual, contentor, execução sem servidor ou serviço gerido — em uma linha cada.
Escrevam as etapas de modernização por ordem, com o benefício esperado de cada uma, e a secção de pressupostos e pontos por apurar.
Verifiquem o desenho contra as cinco perguntas da exposição, e corrijam o que faltar.
Produto esperado: desenho de arquitectura em A3, folha de justificações por componente, lista ordenada de etapas de modernização e secção de pressupostos e pontos por apurar.
Síntese em leitura fácil
- Uma arquitectura responde a cinco perguntas: que componentes, por onde entra, onde ficam os dados, que fronteiras e o que falha.
- O desenho simples tem quatro camadas: entrada, aplicação, dados privados e armazenamento de objectos privado.
- Microserviços resolvem problemas de escala e de equipa; para serviços pequenos, uma aplicação única bem organizada costuma bastar.
- Cloud-native e DevOps significam configuração fora do código, estado fora da máquina e publicação automática e repetível.
- A modernização faz-se por etapas, cada uma com benefício próprio.
- Um bom documento diz também o que ainda não se sabe.
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.
- Um serviço distrital com uma aplicação e duas pessoas na informática deve começar por dividir o sistema em microserviços?
- Porque é que a base de dados não deve ter endereço público, mesmo com palavra-passe forte?
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. Um serviço distrital com uma aplicação e duas pessoas na informática deve começar por dividir o sistema em microserviços?
Resposta: Normalmente não. A divisão acrescenta complexidade de comunicação e de manutenção; justifica-se quando há razão concreta, como partes com ritmos de mudança muito diferentes.
Comentário: A decisão certa depende do problema a resolver, e não da modernidade do vocabulário.
Pergunta 2. Porque é que a base de dados não deve ter endereço público, mesmo com palavra-passe forte?
Resposta: Porque a exposição amplia a superfície de ataque sem necessidade: o acesso deve vir apenas da sub-rede da aplicação, por regra de permissão mínima.
Comentário: É a mesma regra da lição de redes, aplicada agora ao desenho global.