SaaS vs. hospedagem gerenciada vs. auto-hospedagem: escolha com base em quem assume o trabalho

Comece pelo trabalho que a aplicação precisa atender

Escolher onde executar uma aplicação não é apenas decidir entre a nuvem de um fornecedor e um servidor próprio. É decidir quem vai operar as camadas que mantêm a aplicação funcionando — e quem tomará as decisões sobre dados, acesso, configuração e recuperação.

Comece registrando qual tarefa a aplicação precisa realizar, a quais sistemas deve se conectar, quem precisa de acesso e o que acontece se ela ficar indisponível. Em seguida, liste o trabalho operacional que sua equipe consegue assumir de forma confiável. Um modelo que parece simples na hora da contratação ainda pode exigir esforço do cliente em relação a identidade, tratamento de dados, integrações ou restauração do serviço.

Os rótulos são pontos de partida úteis, mas não constituem contratos completos. O escopo de SaaS, hospedagem gerenciada e auto-hospedagem pode variar de um fornecedor ou acordo para outro. Antes de se basear em uma suposição, confirme as responsabilidades na documentação e nos contratos do fornecedor.

• De qual processo de negócio a aplicação depende, e quanto uma interrupção ou perda de dados afetaria esse processo?
• Você precisa alterar a aplicação, sua implantação ou a configuração subjacente?
• Quais integrações, controles de identidade e regras de tratamento de dados são obrigatórios?
• Quem na sua equipe será responsável pela administração, pelo contato com o fornecedor e pelas decisões de recuperação?

Defina os modelos pelo responsável por operar cada camada

SaaS é, em geral, uma aplicação fornecida e operada por um provedor. Normalmente, o provedor opera o serviço e a infraestrutura subjacente; os clientes usam a aplicação e gerenciam seus próprios usuários, configurações e processos de negócio. A divisão exata — especialmente em relação à exportação de dados, identidade, backups e resposta a incidentes — depende do serviço.

Hospedagem gerenciada significa que um provedor opera algumas tarefas de hospedagem ou infraestrutura de uma aplicação, enquanto o cliente continua responsável por pelo menos parte das decisões relacionadas à aplicação e à organização. O termo não define um limite universal. Um provedor pode gerenciar a implantação e as operações rotineiras do serviço; outro pode oferecer apenas uma camada de hospedagem mais restrita. Pergunte o que está incluído, em vez de deduzir isso pelo rótulo.

Na auto-hospedagem, a organização executa a aplicação em uma infraestrutura que controla ou cuja operação organiza. Isso dá à organização controle mais direto sobre a implantação e a configuração, mas também coloca mais trabalho operacional sobre sua equipe ou seus prestadores de serviços. Usar um provedor de infraestrutura em nuvem não transforma automaticamente uma aplicação em SaaS: sua organização ainda pode ser responsável por operar a aplicação.

Uma regra prática útil: diferencie a aplicação da infraestrutura em que ela é executada. O fato de um provedor operar uma camada não significa, por si só, que ele assuma todas as tarefas nas camadas acima ou abaixo dela.

• SaaS: geralmente, o provedor opera o serviço da aplicação; o cliente continua responsável pelo uso, pelos usuários, pelas decisões sobre dados e pela governança.
• Hospedagem gerenciada: o provedor opera as tarefas de hospedagem acordadas; o cliente mantém as responsabilidades que não estiverem explicitamente incluídas.
• Auto-hospedagem: a organização organiza a operação da aplicação e do ambiente, diretamente ou por meio de seus próprios fornecedores de serviços.

Use uma matriz de responsabilidades — e confirme os limites

A matriz abaixo é uma ferramenta de discussão, não uma promessa sobre todos os fornecedores. “Geralmente” descreve uma suposição inicial comum, não um serviço garantido. As responsabilidades variam bastante, especialmente na hospedagem gerenciada. Peça ao provedor que preencha a mesma tabela para a aplicação e o plano específicos que você está considerando.

Algumas tarefas são compartilhadas. Por exemplo, um provedor pode operar os backups da infraestrutura, enquanto o cliente decide quais dados devem ser retidos, quem pode acessá-los e como responder a uma situação de recuperação. Ter um recurso de backup não equivale a ter um plano de recuperação testado.

• Operação da infraestrutura — SaaS: geralmente, o provedor; hospedagem gerenciada: o provedor, dentro do escopo de hospedagem contratado; auto-hospedagem: a organização ou os provedores de infraestrutura escolhidos por ela.
• Instalação e atualização da aplicação — SaaS: geralmente, o provedor controla as atualizações do serviço, de acordo com seu processo de lançamento; hospedagem gerenciada: varia — esclareça quem agenda, aplica e valida as atualizações; auto-hospedagem: a organização planeja e aplica as atualizações, a menos que delegue essa tarefa.
• Backups — SaaS: pergunte o que é copiado, por quanto tempo e se o cliente pode solicitar restaurações; hospedagem gerenciada: confirme o escopo, a frequência, a retenção e quem é responsável pela restauração; auto-hospedagem: a organização precisa providenciar e monitorar os backups ou contratar esse serviço.
• Acesso e identidade — todos os modelos: o cliente precisa definir quem deve ter acesso e gerenciar as autorizações relacionadas ao negócio. Pergunte quais controles de identidade o serviço oferece e qual parte gerencia as contas no nível da plataforma.
• Dados e governança — todos os modelos: o cliente precisa decidir quais dados inserir na aplicação, quem pode usá-los e quais políticas se aplicam. Confirme diretamente com o fornecedor os compromissos assumidos, os locais de armazenamento dos dados e as condições de tratamento.
• Recuperação — todos os modelos: definam quem detecta e comunica incidentes, quem inicia a recuperação, quais opções estão disponíveis e o que o cliente precisa fazer. Não presuma que a responsabilidade pela hospedagem determine um prazo ou resultado de recuperação.
• Configuração e integrações — SaaS: limitadas às configurações e interfaces disponíveis no serviço; hospedagem gerenciada: pode permitir mais flexibilidade no nível da implantação, dependendo do serviço; auto-hospedagem: normalmente oferece o controle mais direto, junto com o trabalho operacional correspondente.

Compare as compensações além do esforço operacional

Controle e esforço costumam se mover em direções opostas, mas não de forma perfeita. SaaS pode reduzir a necessidade de operar a pilha da aplicação, mas talvez limite as opções de implantação ou personalização. A auto-hospedagem pode oferecer controle mais direto, mas esse controle só é útil se alguém puder manter o ambiente. A hospedagem gerenciada pode delegar tarefas operacionais definidas sem necessariamente transferir o controle da aplicação ou a responsabilidade pelas decisões de negócio.

Considere também as dependências e a portabilidade. Um serviço pode depender de configurações, integrações, recursos de identidade ou formatos de dados específicos do provedor. Mudar de modelo pode exigir mais do que copiar um banco de dados: arquivos da aplicação, configurações, credenciais, integrações e acessos de usuários também podem precisar de atenção. Pergunte sobre esses pontos antes de escolher, e não apenas quando estiver planejando sair.

• Controle: quais decisões sobre a aplicação, a implantação e a configuração precisam continuar sob seu controle?
• Personalização: o produto oferece as alterações necessárias ou elas exigem acesso ao ambiente da aplicação?
• Esforço operacional: quem cuidará das atualizações rotineiras, do monitoramento, das verificações de backup, da solução de problemas e da coordenação da recuperação?
• Dependências: quais serviços de identidade, armazenamento, e-mail, API ou outros precisam continuar funcionando para que a aplicação seja útil?
• Portabilidade: você consegue obter cópias utilizáveis dos seus dados e configurações, e o que precisaria ser reconstruído após uma mudança?
• Responsabilidade: quando algo falhar, haverá um contato definido no fornecedor e um caminho claro para as ações do cliente?

Identifique requisitos que podem eliminar um modelo

Alguns requisitos são condições obrigatórias, não preferências. Se um serviço não atender a uma integração necessária, a uma regra de tratamento de dados ou a um processo de recuperação exigido, a redução do esforço operacional não compensará essa falha. Primeiro, registre as condições obrigatórias; depois, compare as opções restantes.

Os requisitos de governança podem envolver aprovação de acesso, auditabilidade, tratamento de dados ou quem pode administrar o serviço. Os detalhes dependem da sua organização e do fornecedor; não presuma que o modelo de implantação, por si só, garanta conformidade. Valide os controles e compromissos contratuais relevantes com o provedor e, quando apropriado, com os especialistas internos.

As necessidades de recuperação merecem atenção especial. Defina quais dados e funções precisam ser restaurados, quem pode autorizar uma restauração e quais evidências você precisa de que o processo funciona. Se as respostas do fornecedor não atenderem ao seu requisito, considere isso um motivo para reavaliar o modelo ou o provedor.

• SaaS pode não ser adequado se uma implantação ou personalização necessária não estiver disponível, ou se as condições de tratamento de dados, integração ou acesso do serviço não atenderem a um requisito obrigatório.
• Hospedagem gerenciada pode não ser adequada se sua equipe precisar de responsabilidades que o provedor não aceita assumir, ou se o limite entre as operações do provedor e as do cliente continuar pouco claro.
• Auto-hospedagem pode não ser adequada se ninguém puder assumir, com responsabilidade definida, as atualizações, os backups, a administração de acessos e a recuperação — ou se a organização não puder sustentar esse trabalho.
• Qualquer modelo pode não ser adequado se o provedor não conseguir explicar como seus dados podem ser exportados, como o acesso é controlado e o que acontece quando você encerra o serviço.

Teste as compensações com uma carga de trabalho realista

Imagine uma pequena equipe de operações que quer uma aplicação para acompanhar projetos internos. A equipe precisa de acesso pelo navegador, de uma conexão com um fluxo de trabalho existente de identidade ou notificações e de uma forma confiável de recuperar registros. Não há na equipe um especialista em infraestrutura.

SaaS pode funcionar para a equipe se o serviço atender ao fluxo de trabalho e aos controles necessários, e se as condições de exportação de dados e recuperação do provedor forem aceitáveis. A hospedagem gerenciada pode funcionar se a equipe precisar de uma implantação específica da aplicação e um provedor assumir claramente as tarefas de infraestrutura que ela não consegue gerenciar. A auto-hospedagem ainda pode ser viável se a organização tiver um operador definido ou suporte contratado e valorizar o controle necessário o bastante para assumir o trabalho contínuo.

Nenhum desses resultados decorre apenas da descrição da carga de trabalho. A equipe deve testar a integração real, esclarecer a administração de contas, analisar os procedimentos de backup e restauração e estimar o trabalho que terá de assumir. O exercício é útil porque transforma “queremos controle” ou “queremos que seja gerenciado” em requisitos verificáveis.

• Liste os recursos e as integrações indispensáveis ao fluxo de trabalho.
• Identifique quem será responsável pela administração da aplicação e pelas alterações de acesso.
• Peça a cada provedor que explique como funciona uma atualização rotineira e uma solicitação de recuperação de dados.
• Registre o que a equipe precisa fazer durante uma interrupção, a saída de um funcionário ou uma migração planejada.
• Elimine as opções que não atendam aos requisitos obrigatórios antes de comparar a conveniência.

Pergunte aos provedores quem cuida das operações rotineiras

Uma conversa útil com o fornecedor pede explicações sobre fluxos de trabalho concretos, não apenas uma lista de recursos incluídos. Solicite respostas tanto sobre a manutenção comum quanto sobre problemas inesperados. Sempre que possível, peça que o provedor diferencie o que ele executa, o que recomenda e o que espera que o cliente faça.

Em uma implantação gerenciada pela Airbip, a Airbip descreve seu serviço como a execução de instâncias de aplicações em cargas de trabalho Docker nos servidores em nuvem da Airbip. Entre os recursos declarados estão roteamento automatizado e certificados TLS por meio do Traefik e do Let’s Encrypt, verificações de DNS, gerenciamento do ciclo de vida do serviço e backups diários, semanais e mensais configuráveis. Esses recursos não respondem a todas as questões de responsabilidade: confirme diretamente os detalhes sobre o escopo e a retenção dos backups, as etapas de restauração, as responsabilidades por acesso e dados e quaisquer outros requisitos. Consulte o site atual da Airbip para ver os planos e as condições comerciais vigentes.

• Quem instala e aplica as atualizações da aplicação? O cliente pode escolher quando elas acontecem?
• Quais atividades de monitoramento e solução de problemas estão incluídas, e em quais situações o cliente precisa agir?
• O que exatamente está incluído em um backup, por quanto tempo ele é retido e como funciona uma restauração?
• Quem gerencia as contas da aplicação, o acesso administrativo e a integração de identidade?
• Quais dados e configurações o cliente pode exportar, em que formato e por qual processo?
• Quem se comunica durante um incidente, e quais informações ou ações são esperadas do cliente?
• Quais integrações, personalizações ou alterações de implantação são compatíveis — e quais estão fora do escopo?
• Onde estão documentados os limites e as exclusões do serviço?

Planeje a exportação de dados, a migração e a saída do serviço

É mais fácil avaliar a portabilidade antes de adotar o serviço. Descubra como exportar registros e arquivos, se as configurações e informações dos usuários podem ser transferidas e se as integrações precisarão ser recriadas. Verifique se a exportação está em um formato utilizável na próxima opção; a existência de um recurso de exportação não garante uma migração simples.

Registre um plano de saída proporcional à importância da aplicação. Identifique quem solicita a exportação, quem a verifica, como o acesso será tratado durante a transição e o que deve acontecer com as cópias mantidas pelo provedor que está saindo. Confirme os prazos, as taxas ou as condições nos termos atuais do fornecedor, em vez de confiar em suposições.

O modelo certo é aquele cujos limites operacionais, nível de controle e caminho de saída se ajustam aos seus requisitos e à sua capacidade. SaaS, hospedagem gerenciada e auto-hospedagem podem ser opções adequadas. A decisão prática não é qual rótulo parece mais seguro, mas se cada responsabilidade importante tem um responsável.

• Peça uma amostra ou uma descrição da exportação de dados antes de assumir um compromisso.
• Identifique os dados da aplicação, arquivos, configurações, contas de usuário e integrações que talvez precisem ser transferidos.
• Esclareça quem validará os dados exportados e o que será considerado uma transição bem-sucedida.
• Analise com o fornecedor as condições de encerramento do serviço, retenção de dados e exclusão.
• Mantenha um registro de responsabilidades com um responsável definido no cliente para cada tarefa que o provedor não aceitar explicitamente.