Escalabilidade e elasticidade: o que você precisa para levar sua empresa para a nuvem

Até 2025, 85% das empresas terá um princípio de nuvem em primeiro lugar — uma maneira mais eficiente de hospedar dados em vez de localmente. A mudança para a computação em nuvem amplificada pelo COVID-19 e o 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 continuando a crescer, 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 são “não imune falhar.” Em dezembro de 2021, Amazon informou vendo várias APIs da Amazon Internet Services and products (AWS) afetadas e, em poucos minutos, muitos websites amplamente usados ​​caíram.

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

Ambos escalabilidade e elasticidade estão relacionadas ao número de solicitações que podem ser feitas simultaneamente em um sistema em nuvem — elas não são mutuamente exclusivas; ambos podem ter que ser suportados separadamente.

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 pace. Portanto, é o crescimento de longo prazo que é estrategicamente planejado. A maioria dos aplicativos B2B e B2C que ganham uso exigirá isso para garantir confiabilidade, alto desempenho e pace 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 em nuvem com fatores de escala aplicados nos níveis de servidor, cluster e rede, reduzindo as despesas de 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 companhias de seguros durante desastres naturais. Em 2020, a NFL conseguiu apoiar-se na AWS para transmitir ao vivo seu rascunho digital, quando precisava de muito mais capacidade de nuvem.

Uma empresa que experimenta 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 Web pública.

Então, sua empresa tem cargas de trabalho previsíveis, altamente variáveis ​​ou ambas?

Trabalhe as opções de dimensionamento com infraestrutura em nuvem

Quando se trata de escalabilidade, as empresas devem estar 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 back-end de dimensionamento não está alinhada com as metas de negócios. Para determinar uma solução do 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 pace de resposta, o número de solicitações, a carga da CPU e o uso de memória para observar o custo dos produtos (COG) associado às despesas da 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 aumentar ou diminuir a escala e é usado para aplicativos que são monolíticos, geralmente criados antes de 2017, e podem ser difíceis de refatorar. Envolve adicionar 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.

Escala horizontal envolve aumentar ou diminuir a escala e adicionar mais servidores à infraestrutura de nuvem unique 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 de arquitetura e design em torno do 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 pace de inatividade mínimo e alto desempenho, armazenamento e memória.

Se você não tiver certeza de qual técnica de dimensionamento melhor se adapta à sua empresa, talvez seja necessário considerar uma plataforma de automação de engenharia de nuvem de terceiros para ajudar a gerenciar suas necessidades, objetivos e implementação de dimensionamento.

Avalie como as arquiteturas de aplicativos afetam a escalabilidade e a elasticidade

Vamos pegar um aplicativo de saúde simples – que também se aplica a muitos outros setores – para ver como ele pode ser desenvolvido em diferentes arquiteturas e como isso afeta a escalabilidade e a elasticidade. Os serviços de saúde estavam sob area of expertise pressão e tiveram que escalar drasticamente durante a pandemia de COVID-19, e poderiam ter beneficiou de soluções baseadas em nuvem.

Em alto nível, existem dois tipos de arquiteturas: monolítica e distribuído. Monolítico (ou monólito modular em camadas, pipeline e microkernel) arquiteturas não são construídos nativamente para escalabilidade e elasticidade eficientes — todos os módulos estão contidos no corpo main do aplicativo e, como resultado, o aplicativo inteiro é implantado como um todo. Existem três tipos de arquiteturas distribuídas: orientadas a eventos, microsserviços e baseado no espaço.

O aplicativo de saúde simples tem um:

• Portal do paciente – para que os pacientes se cadastrem e marquem consultas.
• Portal do médico – para a equipe médica visualizar prontuários, realizar exames médicos e prescrever medicamentos.
• Portal do Administrative center – para o departamento de contabilidade e equipe de suporte receberem pagamentos e solucionarem dúvidas.

Os serviços do health facility estão em alta demanda e, para suportar o crescimento, eles precisam dimensionar os módulos de registro 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 adotam esse modelo tradicional e unificado de design de instrument devido à vantagem da velocidade de lançamento no mercado. Mas não é uma solução ideally suited 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 actual disso.

A maioria dos aplicativos monolíticos america 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 pace 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 pace médio de inicialização (MTTS) — o pace 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 swimming 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, ele publica um evento quando algo perceptível acontece. Isso pode parecer como fazer compras em um website online de comércio eletrônico durante um período movimentado, encomendar um merchandise, mas receber um e mail informando que está esgotado. As mensagens e filas assíncronas fornecem pressão de retorno quando o front-end é dimensionado sem dimensionar o back-end por meio de solicitações de enfileiramento.

Neste estudo de caso de aplicativo de saúde, 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 de recursos valiosos desnecessariamente. Para dimensionamento de banco de dados, a camada de persistência pode ser projetada e configurada exclusivamente para cada serviço para dimensionamento person.

Juntamente com a arquitetura orientada a eventos, essas arquiteturas custam mais em termos de recursos de nuvem do que arquiteturas monolíticas com baixos níveis de uso. No entanto, com cargas crescentes, implementações multitenant e nos casos em que há rajadas de tráfego, elas são mais econômicas. O MTTS também é muito eficiente e pode ser medido em segundos devido aos 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 no espaço

Essa arquitetura é baseada em um princípio chamado processamento espaçado em tuplas — vários 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 ser dimensionados de forma independente. Com o dimensionamento de 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.

O MTTS é extremamente rápido, geralmente levando alguns milissegundos, pois todas as interações de dados são com dados na memória. No entanto, todos os serviços devem se conectar ao dealer e o carregamento de cache inicial deve ser criado com um leitor de dados.

Nesta generation virtual, 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 vantagem competitiva – é isso 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 do negócio.

Sashank é um empreendedor em série com grande interesse em inovação.