As a Service: o que é, SaaS, PaaS, IaaS, custos, riscos e contratação

Entenda o modelo As a Service, diferenças entre SaaS, PaaS e IaaS, TCO, SLA, segurança, lock-in, portabilidade, migração e critérios de contratação.

Confira!

O modelo “as a Service” descreve uma forma de disponibilizar tecnologia, capacidade ou funcionalidade como serviço contínuo, normalmente com consumo recorrente, responsabilidade operacional parcialmente transferida ao provedor e pagamento associado a assinatura, uso, capacidade ou resultado. Em tecnologia da informação, os exemplos clássicos são SaaS, PaaS e IaaS, mas o princípio se expandiu para segurança, backup, rede, dispositivos, infraestrutura e diversas outras ofertas.

A expressão não deve ser usada como sinônimo automático de “cloud”. O NIST define cloud computing por características específicas — autosserviço sob demanda, amplo acesso à rede, pooling de recursos, elasticidade rápida e serviço mensurado — e por modelos como SaaS, PaaS e IaaS. Um contrato recorrente de equipamento ou operação pode ser comercializado como “as a Service” sem necessariamente atender integralmente à definição de cloud computing.

Do ponto de vista do contratante, a decisão não é simplesmente comprar versus alugar. O modelo altera responsabilidades, CAPEX/OPEX, dependência do fornecedor, ciclo de atualização, dados, integração, níveis de serviço, continuidade, segurança, medição e estratégia de saída. Por isso, a avaliação precisa combinar arquitetura técnica, economia do ciclo de vida e governança contratual.

O que significa “as a Service”

O núcleo do modelo é consumir uma capacidade sem assumir necessariamente a propriedade e toda a operação dos ativos que a produzem.

Em uma compra tradicional, o contratante adquire licenças, servidores, equipamentos ou infraestrutura e passa a administrar grande parte do ciclo de vida.

Em um serviço, o provedor pode permanecer responsável por plataforma, manutenção, atualização, capacidade e disponibilidade, conforme o nível contratado.

Serviço não elimina responsabilidade do cliente

Transferir operação não transfere automaticamente responsabilidade por dados, requisitos, integração, conformidade e continuidade.

O cliente continua responsável por definir o que precisa, validar o serviço, controlar acessos, acompanhar desempenho e gerenciar riscos.

Quanto maior a terceirização, maior a importância da governança.

Recorrência e mensuração

O modelo normalmente envolve pagamento periódico.

A métrica pode ser:

• usuário;
• dispositivo;
• capacidade;
• consumo;
• transação;
• volume armazenado;
• instância;
• endpoint;
• site;
• disponibilidade contratada.

A unidade precisa ser verificável para evitar divergências de faturamento.

SaaS, PaaS e IaaS

O NIST organiza três modelos clássicos de serviço de cloud.

SaaS

Em Software as a Service, o consumidor utiliza aplicações operadas pelo provedor.

O usuário normalmente não administra servidores, sistema operacional ou storage subjacente.

Exemplos incluem e-mail corporativo, CRM, colaboração, ERP e plataformas de gestão entregues via Web.

A responsabilidade do cliente se concentra em usuários, configuração permitida, dados, integrações e governança.

PaaS

Em Platform as a Service, o consumidor implanta aplicações sobre uma plataforma disponibilizada pelo provedor.

O provedor administra infraestrutura e grande parte do runtime.

A equipe do cliente controla aplicação, dados e parte das configurações.

PaaS reduz a necessidade de administrar componentes de base, mas pode aumentar dependência de serviços específicos do provedor.

IaaS

Em Infrastructure as a Service, o consumidor provisiona recursos fundamentais como processamento, storage e rede.

O provedor administra a infraestrutura física e a camada de virtualização, enquanto o cliente assume maior responsabilidade por sistemas operacionais, aplicações, configuração e segurança lógica.

O artigo Computação em nuvem na prática aprofunda essa arquitetura.

XaaS: por que o termo se expandiu

O mercado passou a utilizar “XaaS” ou “Everything as a Service” para inúmeras ofertas.

É comum encontrar:

• Backup as a Service;
• Disaster Recovery as a Service;
• Security as a Service;
• Network as a Service;
• Desktop as a Service;
• Device as a Service;
• Storage as a Service;
• Database as a Service.

Esses nomes são úteis para descrever a oferta, mas não substituem a análise do escopo.

Dois serviços com o mesmo rótulo podem ter responsabilidades completamente diferentes.

Modelo tradicional x modelo como serviço

A diferença deve ser observada pelo ciclo de vida.

Dimensão	Compra tradicional	As a Service
Propriedade	cliente	normalmente provedor
CAPEX inicial	maior	geralmente menor
OPEX recorrente	variável	contratualmente previsível
Atualização	cliente	frequentemente provedor
Escala	exige aquisição	pode ser elástica
Operação	mais interna	parcialmente terceirizada
Dependência do fornecedor	menor em alguns casos	potencialmente maior
Saída	ativo permanece	exige plano de transição

Essa tabela não indica qual modelo é melhor.

A decisão depende do caso de uso, horizonte, criticidade e capacidade interna.

CAPEX, OPEX e TCO

Um erro recorrente é comparar somente o desembolso inicial.

O Total Cost of Ownership (TCO) deve considerar:

• aquisição;
• licenças;
• implantação;
• suporte;
• energia;
• espaço;
• pessoal;
• upgrades;
• renovação;
• indisponibilidade;
• descarte;
• migração.

No modelo as a Service, parte desses custos é incorporada à mensalidade.

Isso simplifica algumas previsões, mas não significa custo total necessariamente menor.

Horizonte de análise

Um contrato de três anos pode parecer econômico, enquanto a análise em oito anos pode mostrar cenário diferente.

A comparação precisa usar o mesmo horizonte e o mesmo nível de serviço.

Também é necessário considerar valor residual de ativos comprados e custos de transição ao final do contrato.

Elasticidade e capacidade

Uma vantagem potencial é adaptar capacidade ao consumo.

Em cloud, elasticidade pode ser rápida e automatizada.

Em serviços que dependem de hardware físico, expansão pode exigir prazo de fornecimento.

O contrato deve diferenciar “capacidade disponível para ativação” de “capacidade que será adquirida após solicitação”.

Essa diferença afeta planejamento.

SLA e SLO

O contrato precisa transformar expectativa em métricas.

SLA formaliza compromissos entre provedor e cliente.

SLO descreve objetivos de nível de serviço.

Métricas podem incluir:

• disponibilidade;
• latência;
• tempo de atendimento;
• tempo de solução;
• RPO;
• RTO;
• desempenho;
• capacidade.

Um SLA sem método de medição é difícil de fiscalizar.

Disponibilidade

“99,9%” isolado é insuficiente.

É necessário definir:

• período de medição;
• janela de serviço;
• exclusões;
• manutenção;
• método de cálculo;
• fonte de dados;
• impacto de indisponibilidade parcial.

A mesma porcentagem pode produzir interpretações contratuais diferentes.

Responsabilidade compartilhada

Em serviços de nuvem, segurança e operação são divididas.

O provedor pode proteger datacenter, hipervisor e serviços básicos.

O cliente continua responsável por identidades, permissões, dados, aplicações e configurações dentro de seu domínio.

A fronteira muda entre SaaS, PaaS e IaaS.

Quanto mais alto o nível de abstração, mais responsabilidade operacional fica com o provedor.

Isso não elimina a responsabilidade de governança do contratante.

Dados e propriedade da informação

Contratos precisam esclarecer quem é titular dos dados e como eles podem ser exportados.

Perguntas relevantes:

• onde os dados ficam?
• em que formato?
• como são protegidos?
• como são apagados?
• como ocorre backup?
• qual retenção?
• há suboperadores?
• como funciona exportação?

A saída do serviço depende dessa clareza.

Portabilidade

Portabilidade é a capacidade de mover aplicações, dados e configurações.

Quanto maior o uso de recursos proprietários, mais onerosa pode ser a migração.

Isso não significa evitar serviços proprietários.

Significa avaliar conscientemente o benefício obtido e o custo de saída.

O projeto deve registrar quais componentes criam dependência tecnológica.

Vendor lock-in

Lock-in ocorre quando mudar de fornecedor exige custo, esforço ou risco elevado.

Ele pode ser técnico, comercial ou operacional.

Exemplos:

• APIs proprietárias;
• formato de dados fechado;
• integrações exclusivas;
• conhecimento concentrado;
• licenciamento;
• prazo de migração.

A mitigação começa antes da contratação.

Integração com ambiente existente

Um serviço raramente funciona isolado.

Ele pode depender de:

• identidade;
• DNS;
• rede;
• VPN;
• APIs;
• SIEM;
• ERP;
• sistemas legados;
• dispositivos.

A integração precisa ser tratada como parte do escopo.

O artigo Migração para nuvem discute dependências de transição.

Segurança

Serviço gerenciado não significa serviço seguro por definição.

O contratante deve avaliar:

• autenticação;
• MFA;
• criptografia;
• segregação;
• logging;
• vulnerabilidades;
• gestão de chaves;
• resposta a incidentes;
• patching;
• acesso privilegiado.

A Segurança em nuvem aprofunda riscos e arquitetura.

Continuidade de negócio

O serviço pode depender de Internet, datacenter do provedor, cadeia de fornecedores e APIs.

A análise precisa identificar o impacto quando uma dessas dependências falha.

Para processos críticos, pode ser necessário:

• redundância;
• modo offline;
• contingência manual;
• exportação periódica;
• segundo fornecedor;
• plano de DR.

A continuidade não deve ser presumida porque a solução é “cloud”.

Modelo de suporte

O contrato deve definir canais, horários e níveis de atendimento.

Também precisa separar incidente, solicitação e problema.

Um P1 pode exigir resposta de minutos.

Uma mudança de configuração pode ter prazo diferente.

Sem classificação, a medição perde objetividade.

Atualizações e mudanças do provedor

Em SaaS, o provedor controla grande parte do ciclo de atualização.

Isso reduz esforço interno, mas pode introduzir mudanças de interface ou comportamento.

O contrato e a governança precisam prever comunicação de mudanças relevantes.

Integrações críticas devem possuir testes de regressão.

Licenciamento e crescimento

Planos comerciais podem alterar custo conforme usuários, módulos ou consumo.

O TCO precisa considerar crescimento.

Uma plataforma barata para 20 usuários pode não permanecer competitiva para 2.000.

É necessário modelar cenários.

Shadow IT e contratação descentralizada

A facilidade de contratar SaaS aumenta risco de serviços adquiridos sem análise de TI, segurança ou engenharia.

Isso pode criar dados dispersos, integrações frágeis e custos duplicados.

Governança de portfólio ajuda a identificar sobreposição.

O problema não é SaaS; é ausência de processo.

FinOps e gestão de consumo

Em serviços mensurados, consumo precisa ser acompanhado.

Cloud pode gerar custos variáveis por compute, storage, tráfego e serviços associados.

FinOps combina engenharia, finanças e operação para melhorar visibilidade e responsabilidade sobre consumo.

A métrica deve chegar a equipes que podem agir sobre ela.

Chargeback e showback

Showback mostra consumo por unidade sem necessariamente cobrar internamente.

Chargeback atribui o custo ao centro responsável.

Ambos podem melhorar consciência econômica.

Porém, a modelagem precisa evitar distorções que incentivem decisões técnicas ruins.

Serviço gerenciado x “as a Service”

Um managed service inclui operação realizada por terceiros.

Uma oferta as a Service entrega capacidade recorrente.

Os conceitos podem se sobrepor, mas não são idênticos.

Uma organização pode contratar infraestrutura própria com operação gerenciada.

Também pode consumir SaaS com pouca interação humana do provedor.

Device as a Service

Em Device as a Service, dispositivos podem ser fornecidos com ciclo de vida, suporte e renovação.

O valor depende de incluir logística, inventário, substituição e gestão.

Se o contrato apenas parcela a compra do hardware, o benefício operacional pode ser limitado.

É necessário examinar o escopo real.

Network as a Service

NaaS pode disponibilizar conectividade e funções de rede sob consumo ou assinatura.

Pode envolver SD-WAN, segurança, LAN gerenciada ou recursos de nuvem.

A arquitetura precisa definir fronteira entre rede do cliente e serviço do provedor.

Monitoramento e responsabilidade devem ser transparentes.

Quando o modelo faz sentido

As a Service tende a ser interessante quando:

• demanda varia;
• atualização frequente é necessária;
• equipe interna é limitada;
• velocidade de implantação importa;
• serviço não é diferencial estratégico;
• previsibilidade de OPEX é valorizada;
• escala compartilhada do provedor gera eficiência.

Nenhum desses fatores é suficiente isoladamente.

Quando pode não fazer sentido

Pode ser menos adequado quando:

• operação desconectada é essencial;
• latência local é crítica;
• dados possuem restrições específicas;
• demanda é estável e previsível;
• dependência do fornecedor é inaceitável;
• custo de longo prazo supera alternativa;
• integração legada é muito rígida.

A decisão precisa ser documentada.

Critérios para comparar alternativas

Uma matriz de decisão pode incluir:

Critério	Pergunta
custo	qual TCO no horizonte?
disponibilidade	qual impacto de falha?
segurança	quem controla cada camada?
integração	quais dependências existem?
flexibilidade	é possível aumentar/reduzir?
portabilidade	como sair?
governança	quem acompanha o contrato?
desempenho	requisitos são demonstráveis?

Pesos devem refletir o contexto do negócio.

Levantamento e diagnóstico

Antes de substituir uma plataforma por serviço, é necessário conhecer o ambiente existente.

Inventário deve identificar:

• aplicações;
• usuários;
• integrações;
• dados;
• licenças;
• dependências;
• custos;
• incidentes;
• capacidade.

Um Levantamento Cadastral de Engenharia pode apoiar a recuperação da baseline técnica.

Design Review da solução

Uma proposta as a Service precisa ser avaliada como arquitetura.

É necessário verificar fronteiras, interfaces, disponibilidade, segurança, dados e estratégia de saída.

A Revisão e Validação Técnica de Projetos — Design Review pode comparar requisitos e solução ofertada antes da contratação.

Migração

A migração deve possuir fases.

Uma sequência pode incluir:

1. inventário;
2. preparação;
3. piloto;
4. migração de dados;
5. integração;
6. validação;
7. corte;
8. estabilização;
9. desativação do legado.

O rollback precisa ser definido antes do corte.

Testes e aceite

O aceite deve provar que o serviço atende aos requisitos.

Podem ser testados:

• autenticação;
• integração;
• desempenho;
• disponibilidade;
• backup;
• recuperação;
• exportação;
• logging;
• suporte;
• medição.

O Comissionamento de Equipamentos oferece uma lógica de verificação, evidências e aceite aplicável à infraestrutura tecnológica.

Como estruturar a contratação

O documento técnico deve definir:

• objeto;
• escopo;
• exclusões;
• usuários/capacidade;
• integrações;
• responsabilidades;
• segurança;
• SLA;
• suporte;
• dados;
• medição;
• reajuste;
• transição;
• encerramento.

Quanto mais ambígua a fronteira, maior o risco de aditivos e conflito.

Medição e pagamento

A medição deve usar dados rastreáveis.

Se o contrato cobra por dispositivo, é necessário definir o que caracteriza dispositivo ativo.

Se cobra por armazenamento, deve definir unidade e método.

Se cobra por usuário, precisa diferenciar licenciado, ativo e concorrente.

A regra comercial precisa ser tecnicamente verificável.

Estratégia de saída

Todo serviço recorrente precisa nascer com uma hipótese de saída.

Isso inclui:

• prazo;
• formato de exportação;
• suporte à migração;
• eliminação de dados;
• transferência de documentação;
• continuidade durante transição;
• custos.

Exit plan não significa expectativa de fracasso.

É parte da governança.

Fiscalização e governança

Após contratação, alguém precisa acompanhar SLA, consumo, segurança, mudanças e roadmap.

Relatórios do fornecedor não substituem verificação do contratante.

A governança deve possuir periodicidade, responsáveis, indicadores e fluxo de escalonamento.

Em contratos relevantes, reuniões de serviço e registros formais ajudam a manter rastreabilidade.

Erros recorrentes

Erro	Consequência
comparar só mensalidade	TCO incorreto
SLA genérico	difícil fiscalização
sem plano de saída	lock-in elevado
integração fora do escopo	aditivos
dados sem regras	risco operacional
consumo sem controle	custo imprevisível
responsabilidade ambígua	lacunas de segurança
migração sem rollback	indisponibilidade

Modelagem econômica e ponto de equilíbrio

A comparação econômica deve partir de cenários equivalentes. Uma alternativa própria pode exigir CAPEX inicial maior, mas gerar custo marginal menor ao longo do tempo. Um serviço pode reduzir investimento inicial, porém manter cobrança recorrente enquanto for utilizado. O ponto de equilíbrio depende do horizonte, crescimento, custo de capital e volume de uso.

Uma análise útil trabalha com pelo menos três cenários: demanda conservadora, provável e alta. Para cada um, compara-se desembolso, capacidade, suporte, pessoal, upgrades e custos de saída. Isso evita que uma decisão seja tomada com base apenas na demanda atual.

Também é necessário diferenciar custo evitado de economia real. Se um serviço elimina a necessidade de comprar hardware, existe CAPEX evitado. Mas, se a organização continua mantendo equipe e infraestrutura paralela por dependências legadas, parte da economia prevista pode não se materializar.

SLA: como transformar promessa comercial em requisito verificável

Um SLA deve especificar o que será medido, em qual período, por qual fonte e em qual ponto da cadeia. “Disponibilidade de 99,9%” pode significar disponibilidade da plataforma central, enquanto uma integração essencial permanece indisponível. O contrato precisa dizer qual unidade representa o serviço percebido pelo usuário.

Também é necessário estabelecer exclusões. Janelas de manutenção, falhas de terceiros e eventos classificados como força maior podem ser retirados do cálculo. Se as exclusões forem excessivas, a métrica perde significado operacional.

Service credits são um mecanismo comercial, não uma recuperação automática do impacto do negócio. Em sistemas críticos, a consequência da indisponibilidade pode superar muito o crédito mensal. Por isso, SLA deve ser tratado como controle de desempenho, enquanto continuidade e contingência são tratadas por arquitetura.

Matriz de responsabilidades

Uma contratação madura descreve quem faz o quê ao longo do ciclo de vida. Pode ser utilizada uma matriz RACI ou outra estrutura equivalente para distinguir responsável, aprovador, consultado e informado.

Em SaaS, por exemplo, o fornecedor pode administrar a aplicação, mas o cliente continua responsável por criação de usuários, segregação de funções, classificação de dados e integrações. Em IaaS, a responsabilidade do cliente normalmente aumenta porque sistemas operacionais e aplicações permanecem sob seu controle.

A matriz precisa incluir incidentes, mudanças, backup, restauração, segurança, onboarding, offboarding e encerramento contratual. Ambiguidades nessas interfaces são uma fonte recorrente de lacunas operacionais.

Due diligence do fornecedor

Antes de contratar um serviço relevante, é necessário avaliar não apenas funcionalidades, mas a capacidade do fornecedor de sustentar o serviço. A análise pode incluir histórico, suporte, dependências de terceiros, maturidade de segurança, continuidade, roadmap e capacidade financeira.

Quando o serviço depende de subcontratados ou hyperscalers, essa cadeia também precisa ser compreendida. O contratante não precisa operar cada camada, mas deve saber quais dependências existem e qual responsabilidade o fornecedor assume sobre elas.

Certificações podem apoiar a análise, mas não substituem verificação do escopo. Uma certificação de segurança em determinada operação não significa que todo serviço contratado esteja coberto exatamente da mesma forma.

Dados: exportação, retenção e encerramento

A estratégia de saída começa pela capacidade de recuperar os dados. O contrato deve definir formatos, periodicidade, APIs, exportações em massa, metadados e prazos. Receber apenas relatórios em PDF ao final pode ser insuficiente para migrar uma base operacional.

Também deve ser definido o que acontece com backups e réplicas após encerramento. A exclusão imediata pode impedir recuperação durante transição; retenção indefinida cria risco de privacidade e governança. O prazo precisa ser coerente com a estratégia de migração.

Quando o serviço armazena documentação técnica, modelos, históricos ou dados de ativos, preservar estrutura, relacionamentos e metadados pode ser tão importante quanto exportar arquivos individuais.

Gestão de mudanças contratuais e tecnológicas

Serviços evoluem durante contratos longos. O fornecedor pode alterar interface, arquitetura, limites de consumo, funcionalidades ou dependências. O contratante precisa definir quais mudanças podem ocorrer unilateralmente e quais exigem comunicação, homologação ou aprovação.

Em integrações críticas, uma mudança de API pode impactar sistemas terceiros. Versões, depreciação e prazo de transição precisam ser acompanhados. A governança deve possuir calendário de mudanças e responsáveis por testes.

Do ponto de vista econômico, planos e unidades de cobrança também podem mudar. A estratégia contratual deve prever reajuste, alteração de faixa e mecanismos para evitar surpresa de custo.

FinOps aplicado ao ciclo de vida do serviço

FinOps não se resume a reduzir conta de cloud. A disciplina conecta uso técnico a consequência financeira. Equipes precisam compreender quais escolhas de arquitetura geram consumo e quais recursos permanecem pagos sem entregar valor.

Indicadores úteis incluem custo por usuário, aplicação, transação, ambiente ou unidade de negócio. Esses recortes permitem comparar eficiência ao longo do tempo e identificar capacidade ociosa.

A otimização precisa preservar requisito. Desligar redundância para reduzir custo pode melhorar a fatura e piorar disponibilidade. A decisão correta relaciona economia a impacto técnico e risco.

Operação assistida, handover e estabilização

Depois da migração, um período de operação assistida ajuda a validar comportamento real. Nessa fase, integração, suporte, desempenho, consumo e incidentes são acompanhados com maior intensidade.

O handover para a operação deve consolidar arquitetura, responsabilidades, contatos, SLAs, dashboards, procedimentos, inventário de integrações e plano de escalonamento. Sem essa transferência, o conhecimento permanece concentrado na equipe de projeto ou no fornecedor.

Também é o momento de comparar premissas econômicas com consumo observado. Se a utilização real divergir significativamente da projeção, o modelo financeiro e a capacidade contratada devem ser revistos.

Matriz de riscos para a decisão de contratação

A decisão entre operação própria e serviço recorrente pode ser estruturada por uma matriz de riscos. Cada risco deve ser associado à probabilidade, impacto, controle existente, tratamento proposto e responsável.

Riscos típicos incluem indisponibilidade do provedor, aumento de custo, mudança de API, perda de dados, falha de integração, lock-in e encerramento do fornecedor. O objetivo não é eliminar todos, mas conhecer quais riscos são transferidos, compartilhados ou mantidos pelo contratante.

Essa análise também ajuda a comparar propostas. Um fornecedor mais barato pode transferir ao cliente atividades de backup, integração ou suporte que outra oferta inclui. Sem normalizar responsabilidades, a comparação de preço é incompleta.

Critérios de aceite e início da operação contratual

O início da cobrança recorrente deve estar ligado a uma condição de aceite clara. Assinar o contrato ou disponibilizar credenciais não significa necessariamente que o serviço está pronto para produção.

O aceite pode depender de migração concluída, integrações funcionando, dados carregados, usuários habilitados, testes de desempenho, plano de backup e treinamento. Cada evidência deve ser registrada.

Essa prática reduz disputas sobre início de faturamento e evita que o contratante pague integralmente por uma capacidade ainda indisponível ou parcialmente implementada.

Cenários de sensibilidade para custo, consumo e crescimento

A avaliação econômica não deve usar apenas uma fotografia do consumo atual. Serviços recorrentes podem mudar significativamente de custo quando usuários, volume de dados, tráfego ou capacidade crescem. Por isso, a modelagem deve testar cenários de sensibilidade e identificar quais variáveis têm maior efeito sobre o TCO.

Um exemplo é um serviço cobrado por armazenamento e transferência. O custo inicial pode ser baixo, mas a retenção crescente e a movimentação de grandes volumes podem alterar a curva econômica. Em outro contrato, o principal driver pode ser número de usuários licenciados ou dispositivos gerenciados.

A análise deve incluir faixas de crescimento, reajustes, mudança de plano, descontos por compromisso e eventual redução de consumo. Isso permite identificar o ponto em que outra arquitetura passa a ser economicamente mais eficiente ou em que a renegociação se torna necessária.

O mesmo exercício deve ser feito com risco. Se a dependência do serviço aumenta conforme novas integrações são criadas, o custo de saída também cresce. A decisão econômica precisa considerar não apenas a mensalidade futura, mas o esforço necessário para manter liberdade de migração.

Evidências que devem permanecer após a contratação

A governança do serviço precisa preservar evidências desde o início: baseline de consumo, matriz de responsabilidades, arquitetura aprovada, critérios de aceite, resultados de testes, SLAs, relatórios de desempenho, registros de mudanças e histórico de custos. Sem esse conjunto, a avaliação do fornecedor fica dependente de percepção subjetiva.

Essas evidências também sustentam renovação ou substituição. Ao fim do ciclo contratual, o contratante consegue comparar desempenho prometido e realizado, evolução do TCO, quantidade de incidentes, crescimento do consumo e custo de saída. A decisão seguinte passa a utilizar dados do próprio contrato, e não apenas novas propostas comerciais.

Como regra de fechamento, o contratante deve conseguir relacionar consumo, custo, desempenho, responsabilidades e risco em uma mesma visão de governança. Essa rastreabilidade permite decidir com base em evidências quando manter, ampliar, renegociar ou substituir o serviço ao longo do ciclo contratual.

Considerações finais

“As a Service” é um modelo de consumo e responsabilidade, não apenas uma forma de pagamento.

SaaS, PaaS e IaaS representam níveis diferentes de abstração e controle.

A decisão correta depende de TCO, arquitetura, segurança, continuidade, integração, SLA, governança e estratégia de saída.

O benefício real aparece quando o serviço é especificado como capacidade mensurável e gerenciado ao longo de todo o ciclo de vida.

Referências técnicas

[1] NIST. NIST SP 800-145 — The NIST Definition of Cloud Computing. Disponível em: https://csrc.nist.gov/pubs/sp/800/145/final.

[2] NIST. NIST SP 500-322 — Evaluation of Cloud Computing Services Based on NIST SP 800-145. Disponível em: https://www.nist.gov/publications/evaluation-cloud-computing-services-based-nist-sp-800-145.

[3] NIST. Cloud Computing Standards Roadmap. Disponível em: https://www.nist.gov/publications/nist-cloud-computing-standards-roadmap.

Perguntas frequentes

As a Service é a mesma coisa que cloud computing?

Não necessariamente. SaaS, PaaS e IaaS são modelos clássicos de cloud, mas outras ofertas chamadas as a Service podem não atender a todas as características de cloud definidas pelo NIST.

SaaS, PaaS e IaaS diferem em quê?

Principalmente na divisão de responsabilidades. SaaS entrega a aplicação, PaaS entrega a plataforma para aplicações e IaaS entrega recursos fundamentais de infraestrutura.

As a Service sempre custa menos?

Não. É necessário comparar TCO no mesmo horizonte, incluindo implantação, operação, suporte, crescimento, migração e saída.

O que é vendor lock-in?

É a dificuldade técnica, comercial ou operacional de mudar de fornecedor, causada por dados, APIs, integrações, contratos ou conhecimento específico.

O que deve constar no SLA?

Métrica, período, fonte de dados, níveis de serviço, exclusões, responsabilidades e tratamento quando o objetivo não é atingido.

Por que definir estratégia de saída antes da contratação?

Porque formato de dados, prazos, custos e suporte à transição determinam a capacidade real de migrar para outra solução no futuro.

Materiais técnicos complementares

Conteúdos principais sobre o tema

• Computação em nuvem na prática
• Migração para nuvem

Conteúdos técnicos correlatos

• Segurança em nuvem
• Edge Data Center

Serviços relacionados

• Levantamento Cadastral de Engenharia
• Design Review em Projetos de Engenharia
• Planejamento Técnico de Contratações de Engenharia
• Comissionamento de Equipamentos