Muitos sistemas misturam isso. Uma conta de serviço, uma função de nuvem, um limite de permissões e uma decisão de autorização de aplicativo tornam-se uma única confusão emaranhada. Funciona, mas apenas em um lugar. Uma boa arquitetura de saída torna a identidade compreensível fora do provedor. Quem é o usuário? Qual é a carga de trabalho? O que ele pode acessar? Onde essa política é definida? Essas regras podem ser representadas em outro lugar sem fazer engenharia reversa de todo o aplicativo? Se a resposta for não, o sistema não é portátil.
Os dados são a verdadeira armadilha
A computação geralmente é mais fácil de mover do que os dados. Os dados têm problemas de gravidade, governança, custo e formato. As empresas adoram bancos de dados gerenciados, armazenamentos de objetos, plataformas analíticas e serviços de dados de IA porque eles eliminam a carga operacional. Tudo bem. O problema começa quando as organizações param de pensar em como os dados seriam extraídos, transformados, validados e reidratados em outro lugar.
A arquitetura de saída da nuvem requer um pensamento claro sobre formatos de dados, metadados, linhagem, criptografia, retenção e replicação. Se a única forma utilizável de seus dados estiver dentro de um serviço específico do provedor, você terá um problema de portabilidade. Isso não significa que todo banco de dados deva ser de código aberto ou autogerenciado. Esse é outro extremo e geralmente ruim. Isso significa que os arquitetos devem entender o caminho de saída antes de escolher o serviço.
