Os dados são caros e continuam a crescer. O desafio de gerenciar a infraestrutura de dados inclui tecnologias e custos para coletar, processar e armazenar esses dados. Manter esse custo alinhado e ao mesmo tempo gerenciar os requisitos de conformidade é um desafio constante para os clientes.
Ultimamente, tem havido muitos blogs e discussões sobre modelos e implantações de entrega de SaaS. Uma das discussões recentes é sobre os modelos Bring Your Own Cloud (BYOC), em que a nuvem é paga e fornecida pelo cliente, em vez de o provedor de SaaS pagar a maior parte das contas da nuvem.
Para adotar uma nova plataforma, normalmente é necessário um nível de confiança. Isso começa com o uso da plataforma para casos de uso específicos antes de expandir o uso da tecnologia para outros casos de uso. Como engenheiro testando algo, você deseja um serviço simples e de baixo custo.
Muitas vezes, isso é conseguido por meio de um modelo de locação sem servidor ou compartilhado, com baixo custo de entrada, mas também com um acordo de nível de serviço (SLA) baixo. Muitas vezes a escalabilidade pode ser limitada e, finalmente, a segurança é limitada devido à locação compartilhada. À medida que a organização aumenta a adoção desse serviço, muitas vezes fazem mais sentido serviços dedicados, que podem ter um nível mais alto de desempenho e SLAs de segurança associados a eles.
Se um provedor de soluções estiver lhe dizendo que sua solução de dados ou streaming sem servidor é totalmente elástica e não sofrerá picos, ele provavelmente está superando alguns problemas futuros que você terá. Se isso for verdade, eles consideraram algum nível de capacidade que pode ser usado gratuitamente sob demanda, e você espera que essa capacidade esteja disponível quando necessária, e que outro cliente não a utilize. É por isso que, à medida que os clientes crescem, eles exigem ambientes dedicados acompanhados de garantias de desempenho.
Antes de passarmos às próximas etapas, vamos explicar a economia. Como fornecedor de SaaS de uma plataforma de dados gerenciados, há um custo para entregar o serviço, vamos chamar isso de “imposto sobre a nuvem”. É isso que o provedor de SaaS paga ao provedor de nuvem, seja colocation ou nuvem pública.
Isto significa que, como um negócio SaaS, para que as margens de lucro sejam reportadas aos investidores ou ao público, deve haver uma margem de lucro do “imposto sobre a nuvem” para cobrir a infra-estrutura para fornecer o serviço para obter lucro. Se o fornecedor de SaaS puder transferir o custo dessa infraestrutura para o cliente, então serão possíveis modelos de preços muito mais flexíveis, sem afetar os lucros ou o custo dos produtos.
O modelo BYOC permite que um provedor de SaaS transfira os custos da infraestrutura de volta para o cliente para tomar as decisões de infraestrutura. Mais importante ainda, permite que o fornecedor de SaaS evite ter de incluir o custo da infraestrutura como parte do custo do serviço. Em última análise, isto permite uma melhor precificação do componente de software do serviço. O custo da infraestrutura depende de quão bom é o seu negócio com o provedor de infraestrutura de sua escolha, desde que o provedor de SaaS ofereça suporte ao seu provedor de infraestrutura.
Isso abre uma nova ruga para a discussão. A maioria das organizações tem um nível de compromisso com um ou mais fornecedores de infraestrutura, que pode ser destruído pelo uso de infraestrutura e serviços. Os hiperescaladores maiores (Amazon Web Services (AWS), Microsoft e Google) permitem que uma parte dos gastos comprometidos seja retirada por meio de compras no mercado de soluções de terceiros. Alguns mercados têm limites sobre quanto pode ser retirado dessa forma ou quanto a solução de terceiros conta em relação aos compromissos. Esta não é a história completa, mas já é convincente.
Para otimizar os gastos com infraestrutura, a maioria das organizações emprega planos de poupança com provedores de nuvem. Esses compromissos são essencialmente reservas adquiridas para um determinado tipo de instância por um determinado período de tempo (normalmente de um a três anos). Esses planos de economia podem economizar até 75% do preço de tabela de uma instância. Quando repleto de compromissos, isso pode representar uma economia significativa.
Os planos de poupança normalmente só podem ser usados em instâncias de computação, e não em outros serviços de nuvem do provedor. O benefício da abordagem da Aiven é que usamos apenas computação, armazenamento e rede de nossos parceiros provedores de nuvem; não utilizamos nenhum outro serviço em nuvem, o que nos torna portáteis e eficientes.
Ao adquirir BYOC, você não apenas pode aproveitar melhores descontos do provedor de SaaS, mas também aproveitar os compromissos do provedor de nuvem para o mercado, além das enormes economias de seus planos e compromissos de poupança.
Existem várias maneiras pelas quais o BYOC faz sentido para organizações com grandes compromissos com provedores de nuvem. Provavelmente, isso não faz sentido para organizações que têm contas de nuvem menores que alguns milhões de dólares por ano. Depois de atingir esses níveis, faz muito sentido, pois provavelmente você estará otimizando fortemente os padrões de gastos.
Finalmente, a última vantagem do BYOC tem a ver com a propriedade dos dados. Embora você possa dizer aos auditores que possui os dados ao executar um serviço SaaS, o provedor de SaaS possui a infraestrutura em que você executa e ele possui o armazenamento em que seus dados ficam, pois estão em sua conta na nuvem. Se houver um motivo para você sair desse provedor, você deve agir com cuidado. No entanto, se você estiver no BYOC, você possui a infraestrutura e os dados tecnicamente, pois estão em sua conta na nuvem.
Nota: Tecnicamente, você pode desconectar o Aiven a qualquer momento e seus serviços serão executados até que haja necessidade de ações do plano de controle que possam falhar (mais sobre isso mais tarde). A Aiven controla a criptografia e o acesso aos dados com BYOC enquanto realizamos a automação, incluindo balanceamento, otimização, backups, restaurações e gerenciamento de dados. Temos planos para criar liberdade de dados onde os dados possam ser mais automatizados e portáteis, mas fique atento aos planos para 2024 🙂
Agora, para as desvantagens deste modelo. Nem tudo é perfeito com BYOC. Existem desafios associados a ele, mas também soluções. O primeiro desafio é o modelo de responsabilidade compartilhada. Com o BYOC, a rede é mais complexa, o que significa que as equipes precisam trabalhar juntas para configurá-la e, mais importante, as equipes precisam ter um bom controle de mudanças para não quebrar a rede.
Este foi um problema mais de uma vez para Aiven. Construímos ferramentas especializadas para ajudar no monitoramento e teste de configurações BYOC para garantir que a experiência do cliente seja excelente e a conectividade seja sempre ideal. Estamos muito próximos de lançar nosso BYOC de autoatendimento, que automatiza a troca e implementação de informações. No entanto, o cliente sempre pode desconectar o plano de controle, pois é ele quem tem o controle, e não o provedor de SaaS.
O segundo desafio do BYOC é que o cliente tem compromissos com a nuvem, o que significa que instâncias específicas devem ser usadas em regiões específicas do provedor de nuvem. Na Aiven, executamos principalmente planos padrão para nossos produtos, onde selecionamos a melhor infraestrutura para uma determinada carga de trabalho. Podemos criar, e frequentemente criamos, planos personalizados para necessidades específicas do cliente (semelhantes aos hiperescaladores); isso é algo que a Aiven deve fazer pelo cliente.
Planejamos mudar isso no futuro para permitir que os clientes da Aiven se autoatendam e criem os planos específicos necessários para cumprir os compromissos existentes para certos tipos de instâncias, a fim de cumprir os compromissos dos planos de poupança.
Finalmente, existe o plano de controle. Hoje, a Aiven administra um plano de controle redundante em um único provedor de nuvem em vários continentes. O plano de controle nos permite conduzir a automação, coletar dados de observabilidade e gerenciar nosso ponto de controle único para nosso console, APIs e outras ofertas de produtos associados.
Este modelo mudará à medida que expandirmos nosso plano de controle para ser totalmente multicloud em 2024. Este é apenas o primeiro passo para onde estamos indo. No futuro, a Aiven terá um plano de controle mais federado, onde o plano de controle não possui um único local e os dados podem ser federados entre contas de nuvem dos clientes. Isso elimina quaisquer pontos únicos de falha e torna a soberania dos dados ainda melhor do que é hoje.
Como você pode ver, este não é um simples pró e contra de soluções específicas. Cada cliente e tipo de cliente tem necessidades e exigências diferentes. Ao investir em uma plataforma versus uma solução pontual, existem diferentes abordagens para a proposta de valor certa. Por exemplo, se abordarmos uma pequena equipe de desenvolvimento em busca do Kafka, adotaremos uma abordagem diferente de um varejista global que busca toda a plataforma de dados, incluindo PostgreSQL, Kafka, Flink e ClickHouse.
São necessários vários modelos de entrega, juntamente com flexibilidade de negócios para atender os clientes onde eles estão hoje e para onde vão. Nosso objetivo é ajudar os clientes à medida que eles crescem, desde a pequena startup registrada em nosso programa Cluster 2.0 até a Fortune 500, onde criamos presenças globais únicas. Aiven está aqui para ajudá-lo com a plataforma de dados de código aberto para todos.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
Jonah Kowall formou-se em ciência da computação e foi cofundador de uma das primeiras empresas de filtragem de conteúdo no final da década de 1990. Jonah se tornou um especialista em segurança, comprometendo código com o projeto FreeBSD e ajudou a construir os primeiros algoritmos de cracking sem fio. Jonas…
Este site utiliza cookies para melhorar sua experiência de navegação. Ao continuar, você concorda com o uso de cookies. Para mais informações, consulte nossa Política de Privacidade.
Funcional
Sempre ativo
O armazenamento ou acesso técnico é estritamente necessário para a finalidade legítima de permitir a utilização de um serviço específico explicitamente solicitado pelo assinante ou utilizador, ou com a finalidade exclusiva de efetuar a transmissão de uma comunicação através de uma rede de comunicações eletrónicas.
Preferências
O armazenamento ou acesso técnico é necessário para o propósito legítimo de armazenar preferências que não são solicitadas pelo assinante ou usuário.
Estatísticas
O armazenamento ou acesso técnico que é usado exclusivamente para fins estatísticos.O armazenamento técnico ou acesso que é usado exclusivamente para fins estatísticos anônimos. Sem uma intimação, conformidade voluntária por parte de seu provedor de serviços de Internet ou registros adicionais de terceiros, as informações armazenadas ou recuperadas apenas para esse fim geralmente não podem ser usadas para identificá-lo.
Marketing
O armazenamento ou acesso técnico é necessário para criar perfis de usuário para enviar publicidade ou para rastrear o usuário em um site ou em vários sites para fins de marketing semelhantes.