Entendendo os três tipos de computação em nuvem
Quando uma empresa começa a planejar uma migração para a nuvem, a primeira coisa que sempre perguntam é quais são os três tipos de serviços de cloud disponíveis. A resposta direta é: IaaS, PaaS e SaaS. Mas o que importa de verdade não é decorar os nomes, é saber quando usar cada um e onde as armadilhas estão.
Quais são os três tipos de nuvem que você vai encontrar no mercado
IaaS (Infrastructure as a Service) é onde você aluga servidores virtuais, rede e armazenamento. Você tem controle total do sistema operacional, das configurações de rede e do que roda ali. É o tipo mais próximo de ter um data center próprio, só que sem o capital gasto antecipado. A AWS EC2, o Google Compute Engine e o Azure VMs entram nessa categoria. PaaS (Platform as a Service) tira parte desse peso dos seus ombros. O provedor cuida do sistema operacional, dos patches, da escalabilidade básica. Você sobe o código e ele roda. Heroku, Google App Engine e Azure App Service são exemplos. Para times pequenos que precisam entregar rápido, faz sentido. Para equipes com exigências específicas de compliance ou latência, nem sempre é a melhor escolha.
SaaS (Software as a Service) é o produto pronto. Você não configura nada, não administra nada. Entra, faz login e usa. Salesforce, Slack, Google Workspace. Se o software já resolve o problema do negócio, não tem motivo para recriar algo internamente. O que ninguém conta nos sites de marketing é que a linha entre esses três tipos é mais tênue do que parece. Um serviço pode começar como IaaS e adicionar camadas de abstração até virar PaaS. A AWS Lambda, por exemplo, nasceu como parte de um ecossistema de IaaS mas hoje opera claramente como plataforma. Daí a confusão nas orçamentações.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Uma coisa que vejo repetir é time de engenharia escolher PaaS achando que vai poupar tempo, e depois passar semanas lutando contra as limitações da plataforma. Já vi um caso concreto onde um cliente queria migrar um sistema legado para o Google App Engine e descobriu que a aplicação dependia de acesso direto ao sistema de arquivos e de threads de longa duração que o ambiente simplesmente não suportava. A solução foi manter um conjunto de VMs na GCE e mover apenas os serviços stateless para o App Engine. Dividir o trabalho assim economizou cerca de 40% do custo total comparado a manter tudo em VMs dedicadas. O erro mais comum ao decidir entre esses três tipos é avaliar apenas o custo mensal. O custo operacional real inclui tempo de equipe, complexidade de manutenção, vendor lock-in e a dificuldade de migrar entre provedores. Um serviço SaaS barato pode custar muito caro se sua equipe gasta horas toda semana contornando limitações da plataforma. Um IaaS mal dimensionado pode representar um gasto três vezes maior do que o necessário por falta de automatização.
Outro ponto cego é a governança. Em IaaS, você é responsável por tudo, inclusive pela segurança do sistema operacional. Em PaaS, o provedor protege a infraestrutura mas você ainda precisa configurar adequadamente os access controls da sua aplicação. Em SaaS, a responsabilidade de segurança compartilhada é mínima, mas você também não tem visibilidade sobre como os dados são protegidos no lado do provedor. Se o seu setor exige auditoria detalhada, SaaS pode ser problemático. Na prática, a maioria das empresas bem estruturadas usa os três tipos simultaneamente. Roda um banco de dados em IaaS porque precisa de controle, deploya aplicações em PaaS para ganhar velocidade e usa SaaS para funcionalidades que não fazem parte do core do negócio. A chave é mapear cada workload individualmente antes de decidir, em vez de aplicar uma política uniforme para tudo.
Se você está começando agora, a recomendação mais honesta que posso dar é não tentar migrar tudo de uma vez. Escolha um serviço não crítico, migre para IaaS primeiro para ganhar familiaridade com o modelo, depois avalie se parte dele faz sentido como PaaS. Teste com dados reais, não com estimativas. O tempo que você economiza planejando errado é sempre maior do que o tempo que perde corrigindo a migração.
