Saltar para o conteúdo principal
FromNine
Menu

Engenharia

Bases de cloud que tornam os lançamentos rotineiros.

Construímos bases de cloud e plataformas internas para programadores em que os ambientes são código, os lançamentos são assinados e repetíveis, e cada euro gasto tem um responsável.

Para organizações que operam uma só base de cloud para empresas em vários Estados-Membros, cada uma com o seu regulador.

Fale-nos do seu projetoVer a arquitetura de referência
Engenharia de cloud e plataformas: camadas de capacidadesQuatro camadas sobrepostas em profundidade. De cima para baixo: as cargas de trabalho das equipas de produto, a plataforma interna para programadores, os pipelines de entrega assinada e, na base, a landing zone com identidade, rede e políticas.01Cargas das equipas de produto02Plataforma interna03Pipelines de entrega assinada04Landing zone e políticas
  1. 01Landing zones com políticas como código e localização dos dados definida por carga de trabalho
  2. 02Caminhos padronizados que levam um novo serviço à produção de forma repetível
  3. 03SLO, recuperação testada e custo por produto, visíveis para quem decide

01 Problemas

Sinais de que a base está a travar a sua organização

  1. 01

    Cada ambiente é um caso único

    Os ambientes de teste e de produção diferem de formas que ninguém escreveu, e as correções feitas à mão na consola perdem-se na reconstrução seguinte.

  2. 02

    Um lançamento exige uma reunião

    As implementações são raras, manuais e marcadas para o fim do dia. As equipas acumulam alterações, o que torna cada lançamento mais arriscado.

  3. 03

    A fatura da cloud surpreende toda a gente

    Os custos são visíveis por subscrição, não por produto. A capacidade de GPU para trabalho de IA fica reservada para quem pediu primeiro.

  4. 04

    Ninguém sabe se a recuperação funciona

    Há cópias de segurança. As reposições nunca foram testadas, e os objetivos de tempo de recuperação e de perda de dados nunca foram acordados com o negócio.

02 O que entregamos

O que entregamos

  1. 01 Landing zones e opções de soberania

    Estrutura de contas e subscrições, identidade, rede e regras de proteção nos grandes fornecedores de cloud e nas ofertas de cloud soberana da UE, com políticas como código e localização dos dados por carga de trabalho.

    O que fazemos

    • Conceção da organização, dos grupos de gestão e das contas
    • Rede hub, controlo do tráfego de saída e ligações privadas
    • Políticas como código para localização, cifragem e etiquetagem
    • Correspondência com as medidas do artigo 21.º da Diretiva NIS2 e com as atestações que os seus clientes pedem

    O que recebe

    • Landing zone inteiramente definida em código
    • Biblioteca de políticas com processo de exceções
    • Documento de opções de soberania por classe de carga de trabalho

  2. 02 Infraestrutura como código e plataformas internas para programadores

    Terraform ou OpenTofu e Bicep para a infraestrutura, GitOps para as implementações, Kubernetes ou ambientes de execução geridos onde fazem sentido, e caminhos padronizados para que uma equipa arranque um serviço conforme sem abrir pedidos.

    O que fazemos

    • Biblioteca de módulos de infraestrutura como código
    • GitOps com promoção entre ambientes
    • Plataforma Kubernetes ou alternativas geridas
    • Modelos de serviço e um portal para programadores

    O que recebe

    • Plataforma interna para programadores com caminhos padronizados
    • Ambientes em autosserviço
    • Roadmap da plataforma a cargo de uma equipa de plataforma

  3. 03 Pipelines de entrega e segurança da cadeia de fornecimento

    Pipelines que compilam uma vez, assinam os artefactos, registam a proveniência em linha com o SLSA, gerem bem os segredos e promovem o mesmo artefacto do teste à produção.

    O que fazemos

    • Modelos de pipeline com controlos de qualidade e de segurança
    • Assinatura de artefactos e atestação da proveniência
    • Gestão de segredos e rotação de chaves
    • Regras de promoção e registos de alterações

    O que recebe

    • Modelos de pipeline reutilizáveis
    • Artefactos assinados com proveniência verificável
    • Evidências de lançamento para a gestão de alterações

  4. 04 Observabilidade e SRE

    Objetivos de nível de serviço acordados com o negócio, margens de erro que orientam o ritmo dos lançamentos, OpenTelemetry em toda a stack e um processo de incidentes que serve também as obrigações de notificação do Regime Jurídico da Cibersegurança e do DORA, quando se aplicam.

    O que fazemos

    • Definição dos SLO com os responsáveis pelos serviços
    • Instrumentação com OpenTelemetry e painéis
    • Alertas sobre sintomas, não sobre causas
    • Gestão de incidentes e análises pós-incidente

    O que recebe

    • Catálogo de SLO
    • Stack de observabilidade e painéis
    • Procedimentos de incidentes e de notificação

  5. 05 FinOps e capacidade para IA

    Imputação de custos por produto e por equipa, custos unitários como o custo por transação, e planeamento e controlo de custos da capacidade de GPU para cargas de trabalho de IA.

    O que fazemos

    • Política de etiquetagem e modelo de imputação
    • Métricas de custo unitário por produto
    • Planeamento de compromissos e reservas
    • Agendamento de GPU, quotas e dimensionamento adequado

    O que recebe

    • Painéis de custos por responsável de produto
    • Lista de poupanças com responsáveis
    • Plano de capacidade para IA

  6. 06 Recuperação e saída

    Cópias de segurança e recuperação de desastres com objetivos explícitos de tempo e de ponto de recuperação, testadas com regularidade, e uma estratégia de saída que usa os direitos de mudança de fornecedor previstos no Regulamento dos Dados da UE.

    O que fazemos

    • RTO e RPO acordados por serviço
    • Testes de reposição e de failover
    • Mapeamento das dependências dos serviços críticos
    • Plano de saída e verificação da portabilidade dos dados

    O que recebe

    • Procedimentos de recuperação testados
    • Relatórios dos testes de recuperação
    • Estratégia de saída documentada

03 Arquitetura

Uma arquitetura de referência ilustrativa

O código entra à esquerda e as cargas de trabalho a correr saem à direita. Pelo meio, o pipeline assina o que compila, o registo guarda apenas artefactos assinados e um controlador GitOps promove-os entre ambientes, sob políticas.

Por baixo está a landing zone: estrutura da organização, identidade, rede, chaves, recuperação e controlo de custos, definidos uma vez em código e partilhados por todas as equipas de produto.

Camadas do desenho

Entrega
Repositórios, pipelines, artefactos assinados e promoção GitOps.
Plataforma
A plataforma interna para programadores, as políticas como código e o ambiente de execução onde as equipas de produto implementam.
Landing zone
Organização, identidade, rede, chaves, recuperação e controlos de FinOps.
Operação
Telemetria, SLO, margens de erro e resposta a incidentes em todas as camadas.
Exemplo ilustrativo

  1. Entrega

    • Repositórios de código e IaC
    • Compilar, assinar, atestar
    • Registo de artefactos assinados
    • Promoção GitOps

  2. Plataforma

    • Plataforma interna e caminhos padronizados
    • Políticas como código
    • Kubernetes e serviços geridos
    • Cargas das equipas de produto

  3. Landing zone

    • Estrutura de gestão
    • Identidade e acesso
    • Hub de rede e saída
    • Chaves e segredos
    • Cópias e recuperação
    • Imputação de custos

  4. Operação

    • OpenTelemetry, SLO e margens de erro, resposta a incidentes
Entrega assinada sobre uma landing zone governada por políticas

Arquitetura ilustrativa, não corresponde a um sistema de um cliente.

Ler o diagrama em texto

O percurso principal vai dos repositórios de código e de infraestrutura, através de pipelines que compilam, assinam e atestam, até um registo de artefactos, depois um controlador GitOps e, por fim, as cargas de trabalho das equipas de produto.

Uma plataforma interna para programadores fornece caminhos padronizados até aos pipelines. As políticas como código limitam o controlador GitOps. Uma plataforma de execução com Kubernetes e serviços geridos aloja as cargas de trabalho. As chaves geridas pelo cliente alimentam a camada de políticas.

A landing zone, em baixo, contém a estrutura de gestão, a identidade e o acesso, um hub de rede, as chaves, as cópias de segurança e a recuperação, e os controlos de FinOps. A observabilidade com SLO e resposta a incidentes abrange toda a plataforma.

04 Considerações e limites

Considerações de engenharia e limites

  • A soberania tem vários graus

    Como o tratamos

    Classificamos as cargas de trabalho por sensibilidade e associamos cada classe a uma opção: regiões da UE de um grande fornecedor de cloud, uma oferta de cloud soberana ou infraestrutura privada. As contrapartidas em funcionalidades, custo e operação ficam escritas.

    Limites e dependências

    As ofertas soberanas ficam muitas vezes atrás nos serviços geridos, incluindo os serviços de IA. Algumas cargas de trabalho vão custar mais ou fazer menos nesses ambientes, e isso é uma escolha do negócio.

  • Uma plataforma precisa de um product owner

    Como o tratamos

    Tratamos a plataforma interna como um produto, com utilizadores, roadmap e ciclos de feedback, e ajudamos a montar a equipa que a opera.

    Limites e dependências

    Uma plataforma sem equipa torna-se um estrangulamento. Se não for possível dotá-la de pessoas, recomendamos serviços geridos e menos abstrações.

  • A regulação molda a operação

    Como o tratamos

    A classificação de incidentes, os prazos de notificação e a recolha de evidências ficam integrados no processo de incidentes quando o Regime Jurídico da Cibersegurança ou o DORA se aplicam à sua organização.

    Limites e dependências

    Determinar se a sua organização está abrangida, e como se aplica a transposição nacional, cabe às suas equipas de conformidade e jurídica.

  • O controlo de custos é partilhado

    Como o tratamos

    Tornamos o custo visível por produto e acrescentamos limites como orçamentos, quotas e o encerramento agendado de ambientes parados.

    Limites e dependências

    As maiores poupanças vêm normalmente de decisões de arquitetura e de utilização tomadas pelos responsáveis de produto, e não apenas da plataforma.

05 Como trabalhamos

Como trabalhamos

Primeiro a base, depois uma equipa no caminho padronizado, depois todas as outras.

  1. 01

    Avaliar e classificar

    Cargas de trabalho, sensibilidade dos dados, custos atuais e os controlos que os seus auditores esperam.

    ResultadoClassificação das cargas de trabalho e opções-alvo

  2. 02

    Construir a landing zone

    Tudo como código, revisto com a segurança, com um processo para as exceções.

    ResultadoLanding zone em produção

  3. 03

    Integrar uma equipa piloto

    Uma equipa de produto passa para o caminho padronizado; as dificuldades que encontra moldam a plataforma.

    ResultadoPrimeiro serviço na plataforma

  4. 04

    Alargar e passar o testemunho

    Mais equipas entram, a equipa de plataforma assume a responsabilidade e a recuperação é testada com regularidade.

    ResultadoRoadmap da plataforma e relatórios dos testes de recuperação

06 Controlo humano

Onde as pessoas mantêm o controlo

A automação opera a plataforma. As pessoas são responsáveis pelas decisões que envolvem risco ou custo.

  • As alterações em produção são rastreáveis

    Cada alteração em produção vem de um commit revisto, por isso fica sempre registado quem mudou o quê e quem aprovou.

  • O acesso de emergência é raro e registado

    O acesso de emergência tem duração limitada, exige justificação e é revisto depois.

  • As exceções às políticas têm um responsável

    Quando uma carga de trabalho precisa de uma exceção a uma regra de proteção, um responsável pelo risco identificado aprova-a, com prazo de validade.

  • Os responsáveis pelos serviços definem os objetivos

    Os objetivos de recuperação e os níveis de serviço são acordados com o responsável de negócio de cada serviço, e não definidos apenas pela equipa de plataforma.

07 Tecnologias

Tecnologias com que trabalhamos

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Ofertas de cloud soberana da UE
Infraestrutura e entrega
  • Terraform e OpenTofu
  • Bicep
  • Argo CD e Flux
  • GitHub Actions, GitLab CI e Azure DevOps
Execução
  • Kubernetes e variantes geridas
  • Plataformas serverless e de contentores
  • Service mesh quando compensa
  • Conjuntos de nós com GPU para cargas de IA
Operação
  • OpenTelemetry
  • Prometheus e Grafana
  • Monitorização nativa da cloud
  • Motores de políticas como o OPA

A referência a uma tecnologia descreve a nossa experiência de engenharia. Não implica uma parceria com o respetivo fabricante nem o seu aval.

08 Exemplo

Um exemplo ilustrativo

Exemplo ilustrativo

Uma landing zone partilhada para um grupo com empresas em Portugal e em Espanha

01Situação
As empresas do grupo têm tenants de cloud separados, com controlos diferentes. Em Portugal aplica-se o Regime Jurídico da Cibersegurança, em Espanha a transposição espanhola da Diretiva NIS2, e ninguém consegue mostrar a postura de segurança do grupo numa só vista.
02O que construiríamos
Uma landing zone em código com conjuntos de políticas por empresa, registos partilhados e um processo de incidentes que classifica e encaminha as notificações por país, com as evidências das medidas do artigo 21.º da Diretiva NIS2.
03Onde as pessoas decidem
O responsável pela segurança de cada empresa aprova as exceções às políticas para as suas cargas de trabalho; o CISO do grupo é responsável pela base comum.
04O que mediríamos
Tempo entre a deteção e a classificação de um incidente, percentagem de cargas de trabalho abrangidas pelas políticas e testes de recuperação bem-sucedidos por trimestre.

09 Por setor

No seu setor

  • Administração pública

    Opções de soberania por classe de dados, evidências para o Regime Jurídico da Cibersegurança e planos de saída que resistem ao próximo procedimento de contratação.

  • Serviços financeiros

    Resiliência operacional nos termos do DORA: recuperação testada, supervisão dos terceiros prestadores de serviços de TIC e notificação de incidentes integrada na operação.

Portugal

Evidências produzidas uma vez, para cada supervisor

A Diretiva NIS2 é uma só diretiva com transposições nacionais que diferem no âmbito, no registo e no pormenor das notificações. Em Portugal, o Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025) está em vigor desde 3 de abril de 2026, e o Centro Nacional de Cibersegurança (CNCS) é a autoridade nacional de cibersegurança e o ponto de contacto único.

Às entidades financeiras soma-se o DORA, com notificação de incidentes e supervisão de terceiros próprias. Em Portugal, as autoridades competentes para efeitos do DORA são o Banco de Portugal, a Autoridade de Supervisão de Seguros e Fundos de Pensões (ASF) e a Comissão do Mercado de Valores Mobiliários (CMVM), cada uma relativamente às entidades que supervisiona (Lei n.º 73/2025).

Concebemos landing zones em que a localização dos dados, os registos e a classificação de incidentes são políticas, e não projetos, para que uma nova empresa ou um novo país entre por configuração. Os planos de saída assentam nos direitos de mudança de fornecedor do Regulamento dos Dados da UE e são testados, não apenas escritos.

Perguntas sobre engenharia de cloud e plataformas

Que fornecedor de cloud recomendam?

O que se ajusta às suas cargas de trabalho, aos seus contratos existentes e aos seus requisitos de soberania. Trabalhamos com os grandes fornecedores de cloud e com ofertas soberanas da UE, e documentamos as contrapartidas para que a escolha possa ser defendida no procedimento de contratação e revista mais tarde.

Precisamos de Kubernetes?

Nem sempre. O Kubernetes compensa quando há muitos serviços e uma equipa para operar a plataforma. Para meia dúzia de serviços, as plataformas geridas de contentores ou serverless são muitas vezes mais simples e mais baratas de operar.

Como abordam a segurança?

A segurança está integrada na landing zone e nos pipelines: identidades com o mínimo de privilégios, políticas como código, artefactos assinados e segredos que nunca ficam no código. A própria FromNine tem a certificação ISO/IEC 27001 para a gestão da segurança da informação.

Conseguem reduzir os nossos custos de cloud?

Normalmente, sim, mas não prometemos uma percentagem antes de vermos os dados. Começamos por tornar o custo visível por produto e depois trabalhamos uma lista de poupanças com os responsáveis que podem agir sobre elas.

Como evitamos a dependência de um fornecedor?

Escolhendo de forma deliberada onde depender de serviços próprios de um fornecedor, mantendo a infraestrutura em código e mantendo um plano de saída documentado e testado. O Regulamento dos Dados da UE reforça os seus direitos de mudança de fornecedor; um plano de saída torna-os utilizáveis.

Mostre-nos os seus próximos três lançamentos

Dizemos-lhe o que os tornaria rotineiros e quanto custaria construir e operar essa base.

Fale-nos do seu projetoConhecer arquitetura e consultoria