Este é um artigo traduzido originalmente publicado dia 25/09/2023 pelo Jack Vanlightly no post: "On The Future Of Cloud Services And BYOC". Siga o Jack no LinkedIn para se manter atualizado com novas publicações.
Meu trabalho na Confluent envolve uma mistura de pesquisa, engenharia e ajuda-nos a descobrir a melhor estratégia técnica a seguir. BYOC é algo em que tenho pensado recentemente, então decidi escrever o que penso sobre isso e para onde acho que os serviços em nuvem estão indo em geral.
Traga sua própria nuvem (BYOC) é um modelo de implantação que fica em algum lugar entre um serviço de nuvem SaaS e uma implantação local. O fornecedor implanta seu software em uma VPC na conta do cliente, mas gerencia a maior parte da administração para o cliente. Não é uma ideia nova, o termo Managed Service Provider (MSP) existe desde os anos 90 e refere-se ao termo geral de terceirização de gerenciamento e operações de infraestrutura de TI implantada em data centers de clientes ou de terceiros.
Os MSPs podem ser atraentes para clientes que estão acostumados com o modelo local e auto-hospedado, que desejam manter algum grau de controle e visibilidade, mas não desejam mais operar o software por conta própria. Está se tornando um modelo popular entre start-ups de dados, embora com um novo nome (BYOC). Exemplos são Databricks (os pioneiros modernos do BYOC), StarTree BYOC, Redpanda BYOC e StreamNative BYOC.
As promessas do BYOC parecem ser:
Você obtém melhor segurança mantendo os dados em sua conta.
É mais barato e menor TCO.
Estes parecem plausíveis à primeira vista, mas quando você olha mais profundamente, eles não resistem a um exame minucioso. Além disso, o que falta aqui é tudo o que se abre mão ao adotar esse modelo “por conta própria”. Estas coisas que tanto o cliente quanto o fornecedor perdem:
Agrupamento de recursos/sem servidor: a economia, a elasticidade e a confiabilidade de serviços em nuvem em grande escala que podem utilizar computação efetivamente infinita.
Eficiência operacional: o BYOC tem desvantagens estruturais que acrescentam sobrecarga e atrito extras ao modelo operacional, o que pode se manifestar para o cliente como uma qualidade de serviço mais baixa e para o negócio como uma dificuldade para sustentar seu impulso e evoluir o serviço.
Um limite de responsabilidade claro.
Neste post veremos todos esses pontos com o objetivo de obter uma visão realista dos serviços em nuvem BYOC e SaaS. Também veremos por que as implantações em nuvem BYOC são particularmente atraentes para start-ups, mas acabam sendo uma armadilha arquitetônica de longo prazo.
Databricks são um bom exemplo, quando questionados “[Qual é] o seu pior erro como empresário (e o que você aprendeu com ele)”, Ali Ghodsi da Databrick admitiu :
“Não construir uma oferta SaaS completa desde o primeiro dia e brincar com arquiteturas SaaS semi-híbridas mais “seguras”. A maioria dos atalhos não compensa.”
A promessa de segurança
À primeira vista, parece intuitivo que as coisas em sua conta devam estar seguras e protegidas. No entanto, isso negligencia o fato óbvio de que você está trazendo o produto do fornecedor e seu regime de segurança para sua conta. Se você pensar bem, não é uma questão de qual conta o produto é executado, mas sim de quem tem acesso para implantar o código ou acessar seus dados. Infelizmente, o que isso significa é que a segurança não é uma solução única, mas uma longa lista de tarefas meticulosas que qualquer produto deve realizar, independentemente de onde for executado. Com o BYOC, a maioria dos seus dados nunca sai da sua conta, mas isso não significa que você acabou de resolver a segurança. Os principais riscos permanecem. Quem tem acesso às máquinas onde residem os dados? Quem tem acesso para instalar código nessas máquinas? O que esse código faz? etc.
Com o modelo BYOC, o fornecedor poderia operar em dois extremos:
Extremamente fechado: o fornecedor não tem acesso para implantar código, alterar infraestrutura, depurar, etc.
Extremamente aberto: o fornecedor tem acesso total para implantar, fazer alterações, depurar, acessar instâncias e dados em execução, etc.
O mesmo se aplica a um serviço de nuvem SaaS:
Extremamente fechado: o fornecedor bloqueia totalmente todo o acesso fora de seu próprio plano de controle, assim como no caso extremo de BYOC.
Extremamente aberto: o fornecedor fornece acesso total aos servidores, aplicativos, código e dados para todos (ou pelo menos uma boa parte) de sua equipe.
Restrições fechadas extremas não funcionam na prática porque você não pode responsabilizar o fornecedor pela operação do seu serviço; e a fiabilidade sob essas restrições seria gravemente prejudicada. Quando o fornecedor BYOC precisa depurar problemas em um ambiente por meio de uma chamada Zoom, isso não é nuvem, é apenas um software autogerenciado excessivamente complexo. Os fornecedores que começarem aqui adicionarão rapidamente algum tipo de opção de acesso de emergência para permitir que depurem e remediem incidentes difíceis. No entanto, a segurança é tão forte quanto o elo mais fraco, e o software do agente BYOC que é capaz de abrir um túnel SSH reverso para a nave-mãe altera significativamente a garantia de isolamento.
Por outro lado, restrições abertas extremas não funcionam por razões mais evidentes: simplesmente não há nada que impeça qualquer pessoa, BYOC ou SaaS, de acessar o que quiser.
Nem os fornecedores BYOC nem os provedores de SaaS desejam níveis extremos de restrição e ninguém deve se sentir confortável em deixar ambientes abertos como um vale-tudo.
Na realidade, a melhor implementação de qualquer um dos modelos envolve restrições cuidadosas, camadas, acesso JIT, privilégios mínimos, escalonamentos, registro de auditoria detalhado, integrações de identidade, backups, planejamento de recuperação e outros princípios de segurança de boas práticas. leva tempo.
A segurança não é uma solução única, mas uma longa lista de tarefas meticulosas que qualquer produto deve realizar, independentemente de onde for executado.
O outro lado disso é a soberania . Quem realmente controla os dados? Você pode voltar atrás se precisar em uma situação extrema? Esta parece ser uma vantagem de executar em sua conta. Afinal, se necessário, você poderá revogar o acesso aos seus dados do fornecedor. Mas esse tipo de controle e revogação não é exclusivo dos controles que você tem para bloquear sua conta. Os serviços de nuvem SaaS lidam com isso com um mecanismo que fornece exatamente a mesma coisa: criptografia controlada pelo cliente em repouso (você criptografa seus dados, certo?!). Por exemplo, no Confluent, Snowflake, Mongo e na maioria dos outros produtos de dados SaaS, você pode revogar as chaves de criptografia a qualquer momento para interromper o acesso do fornecedor aos dados.
Se o que realmente nos preocupa é o acesso aos dados , e não a conta em que as máquinas estão, então há algo que resolve essa preocupação, independentemente da conta envolvida: criptografia de ponta a ponta. Se criptografarmos os dados dos clientes, o fornecedor nunca terá acesso a eles. Fazer isso manualmente é complicado, mas muitos fornecedores de SaaS, incluindo o Confluent, estão incluindo criptografia em nível de campo ponta a ponta. A Confluent anunciará uma adição significativa a esse recurso na conferência Current esta semana. A criptografia ponta a ponta é o verdadeiro padrão ouro para confidencialidade/soberania de dados, pois reduz significativamente o risco de dados, independentemente de BYOC ou SaaS. Uma postura de segurança que depende de ter os dados em sua conta não é inerentemente mais segura do que aquela baseada nas melhores práticas de criptografia do setor.
O argumento de que o BYOC é a solução mágica para a segurança é tão simplificado que é essencialmente um disparate. O que é definitivamente verdade é que, com o BYOC, a responsabilidade fica com o cliente. Como ele é implantado no ambiente do cliente, mas não tem exatamente o mesmo nível de confiança do restante do código, o cliente precisa ter certeza de que controla seu acesso a outros sistemas e serviços. Em última análise, o cliente deve investir tempo e dinheiro para bloquear o ambiente e executar a verificação de segurança adequada e a supervisão do monitoramento. É verdade que o cliente obtém mais controle e mais visibilidade, mas também herda o trabalho que isso acarreta. Essas responsabilidades e cargas de trabalho raramente ou nunca são representadas na equação do TCO.
Falando em responsabilidades, é hora de falar sobre BYOC e networking.
As complexidades e os custos da rede BYOC
BYOC não é tão simples quanto inserir uma VPC em sua conta e pronto. O BYOC depende de redes privadas para conectividade entre VPCs (algo que pode ser evitado com SaaS). Esta é uma dor de cabeça adicional para o cliente, que agora deve descobrir uma estratégia de conectividade entre VPCs.
No caso da AWS, a opção gratuita é o peering de VPC, mas isso pode acarretar uma carga operacional significativa devido às diversas complexidades que introduz para o gerenciamento de rede.
As tabelas de roteamento devem ser atualizadas, o que pode ser complexo, especialmente em cenários com diversas VPCs e requisitos de roteamento complexos.
As sobreposições de endereços IP entre VPCs com peering podem causar conflitos e problemas de roteamento.
Pode haver problemas devido a limitações de peering transitivas. Alcançar conectividade transitiva requer configurações adicionais ou o uso do AWS Transit Gateway (não gratuito).
Você deve configurar grupos de segurança e ACLs de rede para permitir o tráfego necessário entre VPCs com peering. Configurações incorretas podem levar a problemas de conectividade ou vulnerabilidades de segurança.
A resolução de DNS entre VPCs com peering pode ser complexa, especialmente se você tiver configurações de DNS personalizadas.
A propagação de rotas e atualizações oportunas são essenciais para a conectividade VPC.
Outra opção gratuita que evita essa complexidade adicional é o Compartilhamento VPC . A ideia dessa arquitetura de rede é que o fornecedor implante diretamente na VPC existente, onde seus aplicativos são implantados. Isso evita a necessidade de interconectividade VPC, mas agora o software do fornecedor opera dentro do mesmo limite de confiança que o restante do código implantado. Segurança e conveniência raramente são amigas.
Para evitar o incômodo operacional do peering de VPC ou o risco de segurança do compartilhamento de VPC, os clientes podem escolher Private Link (PL) ou Transit Gateways (TGW), mas ambos têm um preço. O ponto geral que estou defendendo aqui é que tudo isso aumenta o custo total de propriedade (TCO), porque o cliente deve pagar pelo PL/TGW ou deve assumir os custos adicionais de gerenciamento que o peering de VPC introduz. Isso é algo nunca destacado como custo do BYOC.
A promessa do “É mais barato”
Muitas vezes, o BYOC pode parecer mais barato porque o fornecedor se concentra no preço do software, mas o cliente ainda precisa pagar pela infraestrutura do provedor de serviços em nuvem (CSP). Outros custos, como as responsabilidades adicionais de proteção do ambiente e da rede privada, também não são levados em consideração. O provedor de SaaS, por outro lado, inclui todos os custos, incluindo computação, armazenamento, rede, pessoal/infraestrutura de segurança e suporte subjacentes.
Esse preço inicial BYOC não é o verdadeiro custo que o cliente acabará pagando. Pior ainda, o cliente é cobrado duas vezes e precisa separar quais despesas pertencem ao serviço BYOC em duas faturas diferentes. Os verdadeiros custos de BYOC acabam enterrados em uma montanha de outros custos de CSP.
Uma start-up geralmente não consegue negociar descontos com os CSPs que sejam significativamente melhores do que os descontos dos próprios clientes. É daí que vem o argumento de que o BYOC é mais barato porque os clientes podem aproveitar seus próprios descontos de CSP. Mas com o tempo, à medida que um fornecedor de nuvem cresce, seu consumo coletivo de nuvem cresce muito mais do que todos, exceto os poucos maiores clientes. O que antes era uma desvantagem torna-se uma vantagem, pois o fornecedor consegue negociar grandes descontos que podem ser melhor direcionados à sua carga de trabalho e que podem, em parte, ser repassados aos seus clientes.
Na verdade, o modelo BYOC apresenta algumas tensões e incentivos perversos. A maioria de seus modelos de faturamento é avaliada de acordo com o número de nós sob gerenciamento. A maneira de aumentar a receita é adicionar mais nós ao seu cluster! Uma otimização que reduza a contagem de nós reduzirá a receita. O provedor de SaaS tem o incentivo oposto: ele otimiza sua pilha em todos os níveis para obter o máximo de eficiência de custos e desempenho possível. A Economia 101 nos diz que, dada a elasticidade de preço, à medida que o custo base cai, o preço ideal para o lucro também cai e até mesmo o ganancioso fornecedor de SaaS repassaria as economias aos seus clientes.
Mas a razão mais importante pela qual os serviços em nuvem SaaS têm um melhor potencial para fornecer o serviço mais econômico está relacionada precisamente ao que o BYOC abre mão:
A economia, a elasticidade e a confiabilidade dos serviços em nuvem em grande escala.
A eficiência operacional de serviços de nuvem bloqueados em grande escala.
Em contraste, o BYOC é fundamentalmente um único tenant e normalmente um software local cogerenciado pelo fornecedor. No entanto, depois de ver os benefícios estruturais inerentes às arquiteturas multi-tenant em grande escala, você realmente entende por que os CSPs constroem a grande maioria de seus serviços de dados dessa maneira.
A economia, elasticidade e confiabilidade de sistemas multi-tenant (serverless) em grande escala
Vamos considerar o S3 como um estudo de caso para o sistema multi-tenant (MT) de grande escala. S3 era algo novo, era nativo da nuvem em um mundo que ainda seguia firmemente o modo de pensar local.
Foram quatro atributos que fizeram do S3 um sucesso:
Simples
Custo muito baixo
Livre de escala (no que diz respeito ao cliente, ele não pensa nisso)
Extrema durabilidade (e alta disponibilidade).
Dois engenheiros ilustres, Marc Brooker e Andy Warfield, da AWS, escreveram sobre os benefícios dos sistemas MT em grande escala. Marc Brooker escreveu a excelente postagem no blog intitulada “ Surprising Scalability of Multitenancy ” e Andy Warfield escreveu “ Construindo e operando um sistema de armazenamento bastante grande chamado S3 ”. Vejamos o que dizem sobre a economia e a elasticidade dos sistemas de MT.
Utilização de recursos (também conhecido como custo de infraestrutura)
Uma propriedade fundamental em relação à economia do dimensionamento é que você dimensiona sua infraestrutura para picos de carga, mas extrai o valor do sistema na média de longo prazo. Imagine que você recebe 1 milhão de pedidos por dia e a uma taxa constante por segundo. Isso seria um sonho para a eficiência de custos, porque você poderia dimensionar sua infraestrutura para corresponder exatamente à carga constante do sistema. No entanto, agora imagine que você recebe 1 milhão de pedidos por dia em rajadas de um minuto a cada cinco minutos. Sua carga de pico agora é cinco vezes maior que a média e, portanto, você deve dimensionar seu sistema para ser cinco vezes maior para lidar com a mesma carga total. O mundo real não é constante e quanto maior for o desvio da carga de pico da média, menor será o custo-benefício do seu sistema.
“A lacuna entre “pagar pelo pico” e “ganhar em média” é crítica para entender como a economia dos sistemas em nuvem de grande escala difere dos sistemas tradicionais de tenant único.” Marc Brooker, Escalabilidade surpreendente de multi-tenant .
Cargas de trabalho individuais podem ser intermitentes ou ter mudanças de demanda de hora em hora, o que leva a uma má utilização de recursos, onde você está literalmente jogando dinheiro fora em hardware desperdiçado. No entanto, em um sistema multi-tenant como o S3, à medida que você adiciona mais e mais cargas de trabalho, a demanda agregada tende a se estabilizar. Na verdade, à medida que você agrega mais e mais cargas de trabalho, essa tendência de achatamento torna-se cada vez mais pronunciada.
“Mas, à medida que agregamos milhões de cargas de trabalho, algo muito, muito legal acontece: a demanda agregada se suaviza e se torna muito mais previsível.” Andy Warfield, Construindo e operando um grande sistema de armazenamento chamado S3.
Os sistemas de locatário único não se beneficiam dessas tendências de carga previsíveis e achatadas e, em vez disso, devem ser superdimensionados para lidar com os picos de carga de seu locatário único. O Amazon RDS é um ótimo exemplo de sistema de locatário único que exige provisionamento dedicado frequentemente ocioso.
O RDS (excluindo Aurora) é de locatário único porque é um serviço RDBMS tradicional gerenciado. Você já leu os SLAs S3 e RDS? Você já percebeu que o SLA do RDS possui uma série de exclusões relacionadas a problemas resultantes de sobrecarga de banco de dados e do não cumprimento das diretrizes operacionais pelo cliente (dimensionamento adequado, tempo adequado de tarefas de backup etc.)? Nenhuma dessas exclusões existe para o S3 porque a carga de qualquer cliente único é insignificante em comparação com a carga agregada. Os clientes não têm diretrizes operacionais semelhantes para o S3 porque o S3 não é uma tecnologia da era local. É um serviço multi-tenant em escala de nuvem que distribui um conjunto compartilhado de recursos conforme necessário, dependendo da carga do cliente.
Elasticidade e excesso de capacidade
Muitos sistemas de dados distribuídos e de locatário único podem ser ampliados/reduzidos e alguns podem ser escalonados automaticamente de acordo com a demanda, mas esse escalonamento automático é notoriamente difícil de acertar. O dimensionamento de um sistema de locatário único geralmente envolve a sobrecarga de criar uma nova infraestrutura, drenar nós, potencialmente pausar cargas de trabalho, causar perturbações no software cliente, bem como nos custos de movimentação de dados. Isso o torna mais adequado para mudanças sazonais e outras mudanças lentas previsíveis na carga.
O que é escalonamento em um sistema MT de grande escala? A resposta é que se trata de um escalonamento lógico , não de um escalonamento físico. O dimensionamento lógico pode ser realizado em diversas dimensões (algumas visíveis para o cliente e outras não):
Cotas variáveis e limites de taxas. A expansão é tão rápida quanto o sistema leva para aplicar os novos limites.
Um conjunto superior de cotas/limites de taxa + faturamento com base no consumo. Basta estabelecer um limite superior para o consumo de recursos (taxa de transferência, solicitações/s, etc.) e cobrar do cliente o que ele realmente usa, hora a hora.
Alocação dinâmica de recursos físicos subjacentes a recursos lógicos. Esse tipo de escalonamento lógico pode estar oculto ao cliente, mas pode ser igualmente responsivo. Ele simplesmente expande/diminui a quantidade de infraestrutura física na qual o recurso lógico é executado.
A natureza do escalonamento lógico depende da API do serviço. No caso do Confluent, atualmente são clusters Básicos e Padrão, que na verdade são apenas clusters lógicos. Uma oferta de cluster lógico com escalonamento automático mais sofisticada será anunciada na conferência Current esta semana. Para S3 é um balde e seus objetos.
O Confluent oferece escalonamento automático de clusters lógicos Kafka sem exigir que o cliente espere por qualquer escalonamento físico. O cliente tem um intervalo superior para o tamanho do cluster (em termos de recursos como taxa de transferência e conexões/s) implementado como um conjunto de cotas/limites de taxa. O cliente então simplesmente é cobrado com base no consumo por hora do que foi realmente usado. O S3 é um pouco semelhante: ele aplica limites de taxa superiores e cobra com base no número e nos tipos de solicitações.
Isso se refere ao modo como as arquiteturas MT em grande escala funcionam - a carga de um único cliente é pequena em comparação com a capacidade total! O que o escalonamento automático realmente significa para mim, como cliente, é: limitar meu limite superior com limites de taxa e cobrar apenas pelo consumo que realmente usei. O serviço de nuvem subjacente pode lidar com grandes volumes de tráfego, as mudanças na demanda de qualquer carga de trabalho do cliente são absorvidas no curto prazo e as tendências agregadas são previsíveis o suficiente para que a infraestrutura subjacente possa ser dimensionada antecipadamente. Se a tendência geral para um determinado cluster físico mostrar que a carga agregada está aumentando, o provedor de SaaS poderá aumentar o tamanho do cluster físico muito antes que a carga agregada possa fazer com que o cluster atinja um nível que possa afetar o desempenho.
A elasticidade também desempenha um papel na confiabilidade, pois os picos de carga de trabalho individuais podem ser acomodados sem sobrecarregar o sistema. Contudo, há outra propriedade fundamental que contribui para a confiabilidade: o excesso de capacidade.
Os sistemas de locatário único têm uma margem menor de capacidade extra para trabalhar quando ocorrem falhas ou quando são necessárias operações de manutenção, como implementações de cluster. Por exemplo, um cluster Kafka de três corretores de locatário único perderá 33% de sua capacidade quando um único corretor falhar ou for reiniciado. Cada corretor restante deve passar de 33% a 50% da carga total. Quando um disco ou servidor apresenta desempenho degradado, é necessário expandir o cluster e, em seguida, descomissionar a VM problemática. Esses tipos de operações podem ser demorados e estressantes quando o cluster já está sob carga pesada. Curiosamente, o preço por nó do BYOC, na verdade, incentiva o cliente a implantar menos nós para manter baixos os custos de licenciamento, mas do ponto de vista operacional, está longe de ser a estratégia de implantação ideal.
Em comparação, os sistemas MT de grande escala têm capacidade suficiente para absorver falhas e atualizações de servidores com apenas um impacto mínimo nas cargas de servidores individuais. O hardware degradado é tratado reequilibrando leituras e gravações desses dados em outros servidores com interrupção mínima ou nenhuma interrupção do serviço e substituindo o hardware problemático sem preocupações de sobrecarregar o restante dos servidores.
Tudo isso se traduz em um serviço mais confiável e confiável para clientes com maior eficiência de custos. Há uma razão pela qual os hiperescaladores (AWS, GCP, Azure) não implementam a maioria dos seus serviços como sistemas de locatário único. A economia, a elasticidade, a confiabilidade e a simplicidade que uma verdadeira arquitetura de serviços em nuvem oferece não podem ser refutadas.
Deve-se observar que a AWS agora oferece a maioria de seus serviços de dados inicialmente de locatário único como multilocatários sem servidor. Por exemplo, existe um SKU sem servidor para EMR, Redshift, OpenSearch, Aurora e Database Migration Service (DMS).
Aí vem a verdade fundamental e o principal motivo pelo qual acredito que o futuro dos serviços em nuvem é em grande escala e multilocatário: o S3 é capaz de oferecer incrível durabilidade, escalabilidade e preço baixo porque a própria tecnologia é estruturalmente orientada para fornecer essas coisas. Não há mágica aqui, você constrói a arquitetura de software para suportar os atributos que os clientes precisam.
Eu direi novamente:
“É a tecnologia subjacente que permite os atributos externos que valorizamos, como simplicidade, confiabilidade, elasticidade e eficiência de custos. Obtemos esses atributos-chave porque arquitetamos especificamente para eles”. Jack Vanlightly, esta postagem.
Os sistemas de inquilino único não conseguem igualar o potencial dos sistemas de MT de grande escala nestes atributos críticos. O design subjacente tem propriedades fundamentais inevitáveis.
A eficiência operacional de serviços em nuvem em grande escala (ou “A enorme sobrecarga do BYOC”)
Imagine que você é um engenheiro sênior encarregado de dar suporte e desenvolver um serviço de dados na nuvem. Você preferiria ter que suportar potencialmente dezenas de milhares de clusters locais de locatário único implantados em dezenas de milhares de contas de clientes, com uma ampla variedade de tipos de instância, tipos de armazenamento + tamanhos, com acordos e contratos variados com esses clientes em termos de o tipo de acesso, quem é responsável pelas diversas partes da segurança e operações? Ou você preferiria uma grande frota de servidores com uma arquitetura desagregada implantada em um ambiente uniforme e imaculado, totalmente sob o controle do fornecedor?
Esta arquitetura multi-tenant em grande escala com todos os benefícios das características inerentes, como excesso de capacidade e elasticidade, bem como:
Por cotas de cliente.
Um ambiente estável.
Um conjunto padrão de tipos de instância e armazenamento em que seu software tem um perfil de desempenho bem conhecido.
Um conjunto minimizado de versões e configurações.
Um conjunto padrão de ferramentas e controles de acesso.
Agora imagine que você é um executivo sênior que tem que operar este navio, entregá-lo ao menor preço, ao melhor nível de serviço aos clientes em termos de estabilidade e confiabilidade e, além de tudo isso, ser capaz de evoluir e inovar o produto ao longo do tempo. o longo prazo.
Um desses modelos é sustentável, eficiente e realmente capaz de proporcionar uma ótima experiência aos clientes. O outro é uma espécie de beco sem saída arquitetônico. BYOC é uma rua bastante agradável, mas não leva a lugar nenhum no longo prazo. O modelo de negócios BYOC está em desacordo consigo mesmo, pois exige o gerenciamento e a manutenção de um número cada vez maior de clusters de locatário único com um conjunto diversificado de configurações de hardware e software, ao mesmo tempo em que busca eficiências para mantê-lo competitivo com outros. fornecedores de nuvem. Pior ainda, ele não fornece a experiência simples e prática que tornou serviços como o S3 um sucesso definitivo.
O limite da responsabilidade
BYOC não é apenas uma batalha operacional para o fornecedor, mas também para o cliente. O Modelo de Responsabilidade Compartilhada para BYOC é uma parceria tripartida entre o cliente, o CSP e o fornecedor BYOC. Isto apresenta alguns desafios que podem prejudicar o relacionamento fornecedor-cliente e resultar em serviços de pior qualidade. Pode nem sempre ser claro quem é responsável por quê e a confusão resultante pode ser frustrante para ambas as partes. O cliente que pode estar acostumado com um modelo local (por isso pode ser o motivo pelo qual escolheu BYOC) agora não tem acesso total para depuração e solução de problemas, mas o fornecedor pode ter algumas restrições em vigor que limitam sua capacidade de entrar e remediar . Lembra-se dos dados da solução mágica de segurança da sua conta? Os clientes não querem um modelo de segurança extremamente aberto, por isso há um equilíbrio complicado de restrições e separação de responsabilidades envolvidas.
Quando o sistema cai, os tickets são registrados, o estresse pode aumentar e surgem dúvidas sobre quem é o responsável por essa interrupção. Talvez o cliente tenha sobrecarregado o sistema? Ou talvez seja um bug no software que parece apenas uma sobrecarga? Talvez a culpa seja do CSP, de uma unidade de armazenamento degradada, de uma rede degradada ou apenas do cliente não ter dimensionado o hardware adequadamente? Lembra daquelas exclusões de SLA do RDS?
A fronteira entre responsabilidades é muito mais clara com um serviço de nuvem SaaS. O cliente obtém uma API, um conjunto de cotas e responsabiliza o fornecedor pela qualidade do serviço. A separação de responsabilidades é clara. O cliente pode obter uma taxa limitada, sim, mas isso não sobrecarregará o serviço subjacente em grande escala. Ainda pode haver ambigüidades que surgem, geralmente sobre problemas de desempenho que podem ser causados pelo cliente ou pelo fornecedor. Um bom fornecedor de SaaS terá seu sistema fortemente instrumentado para que os problemas possam ser rapidamente diagnosticados e corrigidos se houver uma causa contínua, como um disco degradado.
A falácia do modelo de implantação múltipla e de stack única
Parece razoável que um fornecedor possa oferecer um modelo de implantação SaaS e BYOC - basta arquitetá-lo para que o plano de dados possa ser colocado em qualquer VPC (de propriedade do cliente ou fornecedor) e o plano de controle permaneça na conta do fornecedor. No entanto, este é o mesmo pensamento de arquitetura local.
O design do software local tende a ser monolítico – tudo em um único binário! Contudo, os sistemas de MT em grande escala não são monolíticos; eles são dissociados em diferentes serviços que podem ser dimensionados e implantados de forma independente. O S3, por exemplo, possui uma camada front-end de endpoints de API, uma frota de armazenamento de discos rígidos, uma camada de gerenciamento de armazenamento e um serviço de namespace. Cada um desses componentes é composto por muitos serviços. Embora essa seja a arquitetura certa para o S3, não é a arquitetura certa para uma implantação de locatário único em pequena escala.
O fornecedor que deseja oferecer um serviço SaaS totalmente gerenciado e BYOC tem duas opções; opte pela pilha única e mantenha o curso com a arquitetura ST tradicional ou opte por oferecer suporte a ST BYOC e MT SaaS. O suporte a duas pilhas requer muito mais trabalho, incluindo desenvolvimento, manutenção, documentação e suporte. A capacidade de executar esse plano é um desafio, para dizer o mínimo.
Além disso, o fornecedor não apenas precisa fazer todas essas coisas bem, mas também obter lucro (ou não ficar sem pista)! Amadurecer e fortalecer duas plataformas ao mesmo tempo não é uma tarefa fácil, forçando o fornecedor a uma posição em que deve delegar seus recursos limitados entre uma plataforma ou outra. Recursos de grande impacto exigirão uma implementação de ST e MT, levando a trabalhos repetidos, semelhantes, mas diferentes, e resultando na incapacidade de amadurecer qualquer uma das plataformas a um nível que possa igualar os concorrentes de SaaS. Enquanto você busca BYOC e Serverless ao mesmo tempo, MongoDB Atlas ou Snowflake acabaram de almoçar. Para uma start-up considerando BYOC vs. SaaS, isso pode se tornar algo existencial!
A single tenant não é o futuro dos serviços em nuvem
Não sou tão contra o BYOC ou o single-tenancy como este post pode parecer até agora.
No que diz respeito à single-tenancy, o Apache Kafka e opções semelhantes de streaming distribuído, como Apache Pulsar, RabbitMQ e bancos de dados como MySQL, Postgres etc., nasceram no mundo local e são as melhores opções nesse contexto. Muitos são projetados com tolerância a falhas e alta disponibilidade, com alguma elasticidade incorporada. Todos esses são ótimos sistemas para execução no mundo local, onde a escala computacional quase infinita da nuvem não está disponível. Passei metade da minha carreira dedicada a trabalhar nesses tipos de sistemas.
Mas na nuvem, temos computação, armazenamento e rede efetivamente infinitos, o que nos permite construir serviços muito maiores. Podemos criar serviços que proporcionem melhor economia, melhor elasticidade e melhor confiabilidade do que qualquer coisa que o mundo local seja capaz. A arquitetura de pool massivo de recursos simplesmente oferece uma relação custo-benefício imbatível que os sistemas de locatário único não conseguem igualar.
Então, por que as start-ups oferecem BYOC como serviços em nuvem? BYOC pode muito bem ser a melhor maneira para uma startup transformar um software autogerenciado em um produto de nuvem MVP. Esse caminho permite que eles tratem a nuvem como uma estrutura de gerenciamento RDS para suas ofertas locais. Também será mais barato para eles avançarem: empresas como Confluent e Snowflake fizeram investimentos muito pesados em infraestrutura de nuvem e margens negativas de nuvem desde o início, à medida que construíam seus negócios de nuvem em escala.
Embora o BYOC possa ser um atalho para um produto em nuvem, ele está muito longe de ser “o futuro da nuvem”.
Os melhores serviços em nuvem aproveitam a escala da nuvem
O BYOC tem um lugar e é mais adequado para start-ups que precisam chegar ao mercado rapidamente. Eu entendo e, honestamente, se eu trabalhasse em uma start-up, eu mesmo poderia considerar esse modelo. Esses sistemas de dados distribuídos de código aberto e disponíveis são projetados para serem tolerantes a falhas e altamente disponíveis e podem fazer o trabalho enquanto a empresa está nos estágios iniciais.
Mas o BYOC não é um modelo de negócio de longo prazo e, uma vez nele, acaba sendo uma armadilha da qual é difícil escapar. Tentar construir e dimensionar um negócio em literalmente dezenas de milhares de pequenos clusters (em comparação com o agregado) distribuídos por milhares de contas de nuvem de clientes é uma arquitetura difícil, tanto para o fornecedor quanto para o cliente.
É muito difícil argumentar francamente que a arquitetura BYOC de locatário único é superior aos sistemas multi-tenant de grande escala do S3, BigQuery ou Spanner. A nuvem permite que você aproveite os benefícios inerentes da computação infinita e elástica para criar serviços mais confiáveis e econômicos do que era possível anteriormente.
A realidade é que os CSPs inovaram em soluções SaaS nativas da nuvem primeiro porque perceberam os benefícios das arquiteturas MT em grande escala. Agora, os fornecedores de software populares viram o sucesso das ofertas de CSP e seguiram seus passos. Entre os fornecedores de software, há pioneiros como a Snowflake, que adotou a arquitetura de nuvem MT SaaS em grande escala desde o início. Outras empresas, como MongoDB e Confluent, também estão amadurecendo rapidamente seus próprios serviços MT SaaS para aproveitar a enorme infraestrutura de computação da nuvem. A Databricks também está migrando rapidamente para SaaS com produtos como armazéns SQL sem servidor.
Os serviços de locatário único da AWS estão sem servidor, como EMR, Redshift, OpenSearch, Aurora e outros. A AWS afirmou que esta mudança “ torna significativamente mais fácil e mais rentável para os clientes modernizarem a sua infra-estrutura...—sem sequer terem de pensar em gerir a infra-estrutura ”.
Não são apenas os benefícios estruturais da MT em grande escala que pretendemos, é a maturidade de segurança que a acompanha. As coisas estão amadurecendo muito rapidamente nesta área, com recursos como criptografia ponta a ponta, Traga sua própria chave (BYOK), rede privada, registro de auditoria, acesso JIT... a lista continua.
Para me repetir novamente, porque este é realmente o insight fundamental aqui:
Os serviços SaaS de nível superior, como o S3, são capazes de oferecer incrível simplicidade, confiabilidade, durabilidade, escalabilidade e preço baixo porque suas tecnologias são estruturalmente orientadas para fornecer essas coisas. Atender clientes em grandes conjuntos de recursos proporciona eficiência e confiabilidade incomparáveis em escala.
BYOC não é essa arquitetura – é a arquitetura local que outra pessoa gerencia junto com você em sua conta na nuvem.
Considerações finais sobre o futuro
A tendência sempre foi para abstrações de nível mais elevado, tornando o engenheiro de software individual cada vez mais produtivo em cada estágio da evolução da nossa indústria. A explosão da nuvem e do SaaS é apenas uma manifestação dessa história de fazer mais com menos.
Embora oferecer uma série de novos recursos aos clientes seja atraente (na verdade, muito difícil de resistir), no final, construir um serviço de nuvem econômico, elástico e confiável é o objetivo principal. Também é o mais difícil de fazer e o mais longo em termos de tempo de engenharia. Confiabilidade e estabilidade são talvez os mais importantes para os clientes, pois nada mais importa se você não tiver isso.
A direção que os serviços em nuvem estão tomando não está de volta à arquitetura local implantada em sua conta de nuvem, mas sim a sistemas MT de grande escala “sem servidor”. Esta mudança para MT em grande escala já está em andamento e a proporção de cargas de trabalho executadas em sistemas de locatário único diminuirá gradualmente ao longo do tempo.
Acho que o mesmo será verdade para BYOC. Assim como os clientes deixaram de armazenar seu próprio hardware para migrar para a nuvem, aqueles que experimentarem o BYOC também migrarão para o SaaS por sua simplicidade, confiabilidade, escalabilidade e economia. Enquanto isso, os fornecedores que se concentram em BYOC se verão perdendo a batalha competitiva contra o SaaS devido aos fatores que descrevi nesta postagem, induzindo-os a mudar para sua própria oferta de SaaS multilocatário ou morrer tentando.
Obrigado por ler.
Comments