Até 2025, 85% das empresas terão o princípio cloud-first — uma maneira mais eficiente de hospedar dados em vez de no local. A mudança para a computação em nuvem amplificada pela COVID-19 e pelo trabalho remoto trouxe uma série de benefícios para as empresas: custos de TI mais baixos, maior eficiência e segurança confiável.
Com essa tendência crescendo, a ameaça de interrupções e interrupções de serviço também está crescendo. Os provedores de nuvem são altamente confiáveis, mas “não são imunes a falhas”. Em dezembro de 2021, a Amazon relatou ter visto várias APIs do Amazon Web Services (AWS) afetadas e, em minutos, muitos sites amplamente usados foram desativados.
Então, como as empresas podem mitigar o risco da nuvem, se preparar para a próxima escassez da AWS e acomodar picos repentinos de demanda?
A resposta é escalabilidade e elasticidade — dois aspectos essenciais da computação em nuvem que beneficiam muito as empresas. Vamos falar sobre as diferenças entre escalabilidade e elasticidade e ver como elas podem ser construídas nos níveis de infraestrutura de nuvem, aplicativo e banco de dados.
Entenda a diferença entre escalabilidade e elasticidade
Tanto a escalabilidade quanto a elasticidade estão relacionadas ao número de solicitações que podem ser feitas simultaneamente em um sistema de nuvem — elas não são mutuamente exclusivas; ambos podem ter que ser suportados separadamente.
A escalabilidade é a capacidade de um sistema permanecer responsivo à medida que o número de usuários e o tráfego aumentam gradualmente ao longo do tempo. Portanto, é o crescimento de longo prazo que é planejado estrategicamente. A maioria dos aplicativos B2B e B2C que ganham uso exigirá isso para garantir confiabilidade, alto desempenho e tempo de atividade.
Com algumas pequenas alterações de configuração e cliques de botão, em questão de minutos, uma empresa pode escalar seu sistema de nuvem para cima ou para baixo com facilidade. Em muitos casos, isso pode ser automatizado por plataformas de nuvem com fatores de escala aplicados nos níveis de servidor, cluster e rede, reduzindo as despesas com mão de obra de engenharia.
Elasticidade é a capacidade de um sistema permanecer responsivo durante rajadas de curto prazo ou altos picos instantâneos de carga. Alguns exemplos de sistemas que enfrentam regularmente problemas de elasticidade incluem aplicativos de emissão de bilhetes da NFL, sistemas de leilão e seguradoras durante desastres naturais. Em 2020, a NFL pôde contar com a AWS para transmitir ao vivo seu rascunho virtual, quando precisava de muito mais capacidade de nuvem.
Uma empresa que enfrenta cargas de trabalho imprevisíveis, mas não deseja uma estratégia de dimensionamento pré-planejada, pode buscar uma solução elástica na nuvem pública, com custos de manutenção mais baixos. Isso seria gerenciado por um provedor terceirizado e compartilhado com várias organizações usando a Internet pública.
Então, sua empresa tem cargas de trabalho previsíveis, altamente variáveis ou ambas?
Descubra opções de dimensionamento com infraestrutura de nuvem
Quando se trata de escalabilidade, as empresas devem ficar atentas ao provisionamento excessivo ou insuficiente. Isso acontece quando as equipes de tecnologia não fornecem métricas quantitativas sobre os requisitos de recursos para aplicativos ou a ideia de escalabilidade de back-end não está alinhada com as metas de negócios. Para determinar uma solução de tamanho certo, o teste de desempenho contínuo é essencial.
Os líderes de negócios que estão lendo isso devem falar com suas equipes de tecnologia para descobrir como eles descobrem seus esquemas de provisionamento de nuvem. As equipes de TI devem medir continuamente o tempo de resposta, o número de solicitações, a carga da CPU e o uso da memória para observar o custo dos produtos (COG) associado às despesas com a nuvem.
Existem várias técnicas de dimensionamento disponíveis para organizações com base nas necessidades de negócios e restrições técnicas. Então, você vai aumentar ou diminuir?
Escala vertical envolve escalar para cima ou para baixo e é usado para aplicativos monolíticos, geralmente criados antes de 2017, e podem ser difíceis de refatorar. Isso envolve a adição de mais recursos, como RAM ou poder de processamento (CPU) ao servidor existente quando você tem uma carga de trabalho maior, mas isso significa que o dimensionamento tem um limite com base na capacidade do servidor. Não requer alterações na arquitetura do aplicativo, pois você está movendo o mesmo aplicativo, arquivos e banco de dados para uma máquina maior.
Escalonamento horizontal envolve escalar para dentro ou para fora e adicionar mais servidores à infraestrutura de nuvem original para funcionar como um único sistema. Cada servidor precisa ser independente para que os servidores possam ser adicionados ou removidos separadamente. Isso envolve muitas considerações arquitetônicas e de design em relação ao balanceamento de carga, gerenciamento de sessão, armazenamento em cache e comunicação. A migração de aplicativos herdados (ou desatualizados) que não são projetados para computação distribuída deve ser refatorada com cuidado. O dimensionamento horizontal é especialmente importante para empresas com serviços de alta disponibilidade que exigem tempo de inatividade mínimo e alto desempenho, armazenamento e memória.
Se você não tiver certeza de qual técnica de dimensionamento é mais adequada à sua empresa, talvez seja necessário considerar uma plataforma de automação de engenharia em nuvem terceirizada para ajudar a gerenciar suas necessidades, metas e implementação de dimensionamento.
Avalie como as arquiteturas de aplicativos afetam a escalabilidade e a elasticidade
Vamos usar um aplicativo de saúde simples – que se aplica a muitos outros setores também – para ver como ele pode ser desenvolvido em diferentes arquiteturas e como isso afeta a escalabilidade e elasticidade. Os serviços de saúde estavam sob forte pressão e tiveram que escalar drasticamente durante a pandemia de COVID-19, e poderiam ter se beneficiado de soluções baseadas em nuvem.
Em alto nível, existem dois tipos de arquitetura: monolítica e distribuída. As arquiteturas monolíticas (ou em camadas, monólito modular, pipeline e microkernel) não são construídas nativamente para escalabilidade e elasticidade eficientes — todos os módulos estão contidos no corpo principal do aplicativo e, como resultado, todo o aplicativo é implementado como um todo. Existem três tipos de arquiteturas distribuídas: orientada a eventos, microsserviços e baseada em espaço.
O aplicativo simples de assistência médica tem:
Os serviços do hospital estão em alta demanda e, para suportar o crescimento, precisam escalar os módulos de cadastro de pacientes e agendamento de consultas. Isso significa que eles só precisam dimensionar o portal do paciente, não os portais do médico ou do consultório. Vamos detalhar como esse aplicativo pode ser construído em cada arquitetura.
Arquitetura monolítica
As startups habilitadas para tecnologia, inclusive na área da saúde, geralmente seguem esse modelo tradicional e unificado para design de software devido à vantagem de velocidade de lançamento no mercado. Mas não é uma solução ideal para empresas que exigem escalabilidade e elasticidade. Isso ocorre porque há uma única instância integrada do aplicativo e um único banco de dados centralizado.
Para dimensionamento de aplicativos, adicionar mais instâncias do aplicativo com balanceamento de carga acaba dimensionando os outros dois portais, bem como o portal do paciente, mesmo que a empresa não precise disso.
A maioria dos aplicativos monolíticos usa um banco de dados monolítico — um dos recursos de nuvem mais caros. Os custos da nuvem crescem exponencialmente com a escala, e esse arranjo é caro, especialmente em relação ao tempo de manutenção para engenheiros de desenvolvimento e operações.
Outro aspecto que torna as arquiteturas monolíticas inadequadas para suportar elasticidade e escalabilidade é o tempo médio de inicialização (MTTS) — o tempo que uma nova instância do aplicativo leva para iniciar. Geralmente, leva vários minutos devido ao grande escopo do aplicativo e do banco de dados: os engenheiros devem criar as funções de suporte, dependências, objetos e pools de conexão e garantir a segurança e a conectividade com outros serviços.
Arquitetura orientada a eventos
A arquitetura orientada a eventos é mais adequada do que a arquitetura monolítica para dimensionamento e elasticidade. Por exemplo, publica um evento quando algo perceptível acontece. Isso pode parecer como fazer compras em um site de comércio eletrônico durante um período movimentado, solicitar um item, mas receber um e-mail informando que está esgotado. Mensagens e filas assíncronas fornecem contrapressão quando o front-end é dimensionado sem dimensionar o back-end ao enfileirar solicitações.
Neste estudo de caso de aplicação de assistência médica, essa arquitetura distribuída significaria que cada módulo é seu próprio processador de eventos; há flexibilidade para distribuir ou compartilhar dados em um ou mais módulos. Há alguma flexibilidade em nível de aplicativo e banco de dados em termos de escala, pois os serviços não são mais acoplados.
Arquitetura de microsserviços
Essa arquitetura vê cada serviço como um serviço de propósito único, dando às empresas a capacidade de dimensionar cada serviço de forma independente e evitar o consumo desnecessário de recursos valiosos. Para dimensionamento de banco de dados, a camada de persistência pode ser projetada e configurada exclusivamente para cada serviço para dimensionamento individual.
Juntamente com a arquitetura orientada a eventos, essas arquiteturas custam mais em termos de recursos de nuvem do que as arquiteturas monolíticas com baixos níveis de uso. No entanto, com cargas crescentes, implementações multitenant e em casos onde há rajadas de tráfego, eles são mais econômicos. O MTTS também é muito eficiente e pode ser medido em segundos devido a serviços refinados.
No entanto, com o grande número de serviços e a natureza distribuída, a depuração pode ser mais difícil e pode haver custos de manutenção mais altos se os serviços não forem totalmente automatizados.
Arquitetura baseada em espaço
Essa arquitetura é baseada em um princípio chamado processamento espaçado em tupla — múltiplos processadores paralelos com memória compartilhada. Essa arquitetura maximiza a escalabilidade e a elasticidade em nível de aplicativo e banco de dados.
Todas as interações do aplicativo ocorrem com a grade de dados na memória. As chamadas para a grade são assíncronas e os processadores de eventos podem escalar independentemente. Com o dimensionamento do banco de dados, há um gravador de dados em segundo plano que lê e atualiza o banco de dados. Todas as operações de inserção, atualização ou exclusão são enviadas ao gravador de dados pelo serviço correspondente e enfileiradas para serem coletadas.
MTTS é extremamente rápido, geralmente levando alguns milissegundos, já que todas as interações de dados são com dados na memória. No entanto, todos os serviços devem se conectar ao broker e o carregamento inicial do cache deve ser criado com um leitor de dados.
Nesta era digital, as empresas desejam aumentar ou diminuir os recursos de TI conforme necessário para atender às demandas em constante mudança. O primeiro passo é passar de grandes sistemas monolíticos para arquitetura distribuída para ganhar uma vantagem competitiva – isso é o que Netflix, Lyft, Uber e Google fizeram. No entanto, a escolha de qual arquitetura é subjetiva e as decisões devem ser tomadas com base na capacidade dos desenvolvedores, carga média, carga de pico, restrições orçamentárias e metas de crescimento de negócios.
Sashank é um empreendedor em série com grande interesse em inovação.
DataDecisionMakers
Bem-vindo à comunidade VentureBeat!
DataDecisionMakers é onde os especialistas, incluindo o pessoal técnico que trabalha com dados, podem compartilhar insights e inovação relacionados a dados.
Se você quiser ler sobre ideias de ponta e informações atualizadas, práticas recomendadas e o futuro dos dados e da tecnologia de dados, junte-se a nós no DataDecisionMakers.
Você pode até considerar contribuir com um artigo de sua autoria!
Leia mais de DataDecisionMakers
