No entanto, as organizações devem pesar as vantagens de aprofundar a adoção sem servidor, especialmente com abstrações proprietárias, como funções duráveis. Os modelos sem servidor promovem agilidade e eficiência, mas também podem aumentar a dependência do fornecedor. Por exemplo, a migração de fluxos de trabalho complexos de funções duráveis do AWS Lambda para outra plataforma de nuvem (ou de volta para a infraestrutura native) será cara e complexa porque o código depende de APIs e orquestração específicas da AWS que não se traduzem diretamente no Microsoft Azure, no Google Cloud ou em opções de código aberto.
Há também uma consideração arquitetônica mais ampla. Serverless, por sua própria natureza, espera ausência de estado e capacidade de composição, mas também introduz novos padrões para observabilidade, testes e solução de problemas operacionais. Embora as funções duráveis do AWS Lambda tornem a orquestração do fluxo de trabalho menos onerosa, elas também aumentam a “mágica” que deve acontecer nos bastidores, às vezes tornando a depuração e a compreensão de falhas entre etapas mais desafiadoras. A visibilidade, a conformidade e o controle de custos em toda a empresa exigem investimentos em novas práticas de monitoramento e, possivelmente, em algumas ferramentas proprietárias ou de terceiros.
Prós e contras do aprisionamento sem servidor
Alguns membros da comunidade da nuvem adotaram uma abordagem míope em relação ao aprisionamento do fornecedor, soando alarmes a qualquer sinal de adoção de tecnologia proprietária. Na realidade, evitar completamente o aprisionamento não é prático, e buscar a portabilidade absoluta pode prejudicar o acesso à inovação genuína, como as funções duráveis Lambda. O cálculo deve concentrar-se na gestão de riscos e nas estratégias de saída: O valor entregue pela automação, recuperação de erros incorporada e eficiência operacional justifica a maior dependência de um fornecedor de nuvem específico nesta fase da sua evolução?