A Escalabilidade é um componente essencial do software empresarial. Priorizá-la desde o início leva a menores custos de manutenção, melhor experiência do usuário e maior agilidade.

O desenho de software é um ato de equilíbrio onde os desenvolvedores trabalham para criar o melhor produto dentro das restrições de tempo e orçamento do cliente.

Não há como evitar a necessidade de comprometimento. É preciso fazer tradeoffs para atender aos requisitos de um projeto, sejam eles técnicos ou financeiros.

Muitas vezes, porém, as empresas priorizam o custo em relação à escalabilidade ou até mesmo dispensam totalmente sua importância. Isto é infelizmente comum em grandes iniciativas de dados, onde os problemas de escalabilidade podem afundar um projeto promissor.

A escalabilidade não é uma “característica de bônus”. É a qualidade que determina o valor de vida útil do software, e construir com escalabilidade em mente economiza tempo e dinheiro a longo prazo.

O que é escalabilidade?

Um sistema é considerado escalável quando não precisa ser redesenhado para manter um desempenho efetivo durante ou após um aumento íngreme na carga de trabalho.

“Carga de trabalho” poderia se referir a usuários simultâneos, capacidade de armazenamento, o número máximo de transações tratadas ou qualquer outra coisa que empurre o sistema para além de sua capacidade original.

Scalabilidade não é um requisito básico de um programa em que um software não escalável pode funcionar bem com capacidade limitada.

No entanto, ele reflete a capacidade do software de crescer ou mudar com as demandas do usuário.

Qualquer software que possa expandir além de suas funções básicas – especialmente se o modelo de negócio depender do seu crescimento – deve ser configurado para escalabilidade.

Os benefícios de um software escalável

A escalabilidade tem benefícios tanto a longo como a curto prazo.

No início, permite que uma empresa compre apenas o que precisa imediatamente, não todos os recursos que possam ser úteis no futuro.

Por exemplo, uma empresa que lança um programa piloto de inteligência de dados pode escolher um pacote de análise empresarial massiva, ou pode começar com uma solução que lide apenas com as funções que precisa no início.

Uma escolha popular é um painel de controle que puxa os resultados de suas fontes de dados primários e software empresarial existente.

Quando eles crescem o suficiente para usar mais programas analíticos, esses fluxos de dados podem ser adicionados ao dashboard em vez de forçar a empresa a fazer malabarismos com múltiplos programas de visualização ou construir um sistema totalmente novo.

A construção desta forma prepara para o crescimento futuro enquanto cria um produto mais enxuto que se adapta às necessidades atuais sem complexidade extra.

Requer um menor gasto financeiro inicial, o que é uma grande consideração para executivos preocupados com o tamanho de grandes investimentos em dados.

Scalabilidade também deixa espaço para mudar as prioridades. Esse pacote analítico de prateleira pode perder relevância à medida que a empresa se desloca para atender às demandas de um mercado em evolução.

A escolha de soluções escaláveis protege o investimento inicial em tecnologia. As empresas podem continuar usando o mesmo software por mais tempo porque ele foi projetado para crescer junto com elas.

Quando chega a hora de mudar, construir um software sólido e escalável é consideravelmente mais barato do que tentar adaptar programas menos ágeis.

Tem também um tempo de “rampa” mais curto para trazer novos recursos online do que para implementar um software totalmente novo.

Como um benefício colateral, a equipe não precisará de muito treinamento ou persuasão para adotar esse sistema atualizado. Eles já estão familiarizados com a interface, então trabalhar com os recursos adicionais é visto como um bônus ao invés de uma tarefa.

The Fallout from Scaling Failures

Então, o que acontece quando o software não é escalável?

No início, a fraqueza é difícil de detectar. A carga de trabalho é leve nos estágios iniciais de um aplicativo. Com relativamente poucos usuários simultâneos não há muita demanda na arquitetura.

Quando a carga de trabalho aumenta, surgem problemas. Quanto mais dados são armazenados ou usuários simultâneos o software coleta, mais tensão é colocada na arquitetura do software.

Limitações que não pareciam importantes no início se tornam uma barreira à produtividade. Os patches podem aliviar alguns dos problemas iniciais, mas os patches adicionam complexidade.

Complexidade torna o diagnóstico de problemas em uma base contínua mais tedioso (tradução: mais caro e menos eficaz).

Quando a carga de trabalho aumenta além da capacidade do software de escalar, o desempenho cai.

Os usuários experimentam tempos de carregamento lentos porque o servidor leva muito tempo para responder às solicitações. Outros problemas potenciais incluem a diminuição da disponibilidade ou mesmo a perda de dados.

Tudo isso desencoraja o uso futuro. Os funcionários encontrarão soluções para software não confiável a fim de realizar seus próprios trabalhos.

Isso coloca a empresa em risco de quebra de dados ou pior.

Quando o software está voltado para o cliente, a falta de confiabilidade aumenta o potencial de churn.

Google descobriu que 61% dos usuários não darão uma segunda chance a um aplicativo se eles tiverem uma primeira experiência ruim. 40% vão diretamente para o produto de um concorrente.

As questões de escalabilidade também não são apenas um erro de principiante cometido por pequenas empresas. Até mesmo a Disney teve problemas com o lançamento original do seu aplicativo de Aplausos, que foi feito para dar aos espectadores uma maneira extra de interagir com os programas favoritos da Disney. O aplicativo não conseguiu lidar com a enchente de usuários de streaming de vídeo simultâneo.

Frustrados fãs deixaram críticas negativas até que o aplicativo tivesse uma única estrela na loja do Google Play. Os funcionários da Disney tiveram que derrubar o aplicativo para reparar os danos, e a publicidade negativa foi tão intensa que nunca voltou a ficar online.

Definindo Prioridades

Algumas empresas não conseguem priorizar a escalabilidade porque não vêem a utilidade imediata da mesma.

A escalabilidade é posta de lado em favor da velocidade, ciclos de desenvolvimento mais curtos, ou custo mais baixo.

Existem na verdade alguns casos em que a escalabilidade não é uma prioridade principal.

Software que pretende ser um protótipo ou prova de conceito de baixo volume não se tornará grande o suficiente para causar problemas.

Likewise, software interno para pequenas empresas com um limite fixo baixo de usuários em potencial pode definir outras prioridades.

Finalmente, quando a conformidade com ACID é absolutamente obrigatória, a escalabilidade leva um lugar secundário à confiabilidade.

Como regra geral, porém, a escalabilidade é mais fácil e menos intensiva em recursos quando considerada desde o início.

Por um lado, a escolha do banco de dados tem um enorme impacto na escalabilidade. A migração para uma nova base de dados é cara e demorada. Não é algo que possa ser feito facilmente mais tarde.

Princípios de Escalabilidade

Os fatores transversais afetam a escalabilidade geral do software:

Utilização

Utilização mede o número de usuários ou conexões simultâneas possíveis. Não deve haver limites artificiais de uso.

Aumentar deve ser tão simples quanto disponibilizar mais recursos para o software.

Dados armazenados no máximo

É especialmente relevante para sites com muitos dados não estruturados: conteúdo carregado pelo usuário, relatórios do site e alguns tipos de dados de marketing.

Projetos de dados científicos também se enquadram nesta categoria. A quantidade de dados armazenados por estes tipos de conteúdo pode aumentar drasticamente e inesperadamente.

Se o máximo de dados armazenados pode escalar rapidamente depende muito do estilo do banco de dados (servidores SQL vs NoSQL), mas também é crítico prestar atenção à indexação adequada.

Código

Desenvolvedores inexperientes tendem a ignorar as considerações de código ao planejar a escalabilidade.

Código deve ser escrito para que possa ser adicionado ou modificado sem refatorar o código antigo. Bons desenvolvedores visam evitar duplicação de esforços, reduzindo o tamanho geral e complexidade da base de código.

Aplicações crescem de tamanho conforme evoluem, mas manter o código limpo minimizará o efeito e evitará a formação de “código spaghetti”.

Escalar os Vs Escalar para cima

Escalar para cima (ou “escalar vertical”) envolve crescer usando hardware mais avançado ou mais forte. Espaço em disco ou uma unidade de processamento central (CPU) mais rápida é usada para lidar com o aumento da carga de trabalho.

Escalar para cima oferece melhor desempenho do que escalar para fora. Tudo está contido em um só lugar, permitindo retornos mais rápidos e menos vulnerabilidade.

O problema com o escalonamento para cima é que só há muito espaço para crescer. O hardware fica mais caro à medida que se torna mais avançado. A certa altura, as empresas vão contra a lei de diminuir os retornos na compra de sistemas avançados.

Também leva tempo para implementar o novo hardware.

Por causa destas limitações, o escalonamento vertical não é a melhor solução para software que precisa crescer rapidamente e com pouca atenção.

O escalonamento (ou “escalonamento horizontal”) é muito mais amplamente utilizado para fins empresariais.

Quando se faz o escalonamento, o software cresce usando mais – não mais avançado – hardware e espalhando o aumento da carga de trabalho pela nova infra-estrutura.

Os custos são menores porque os servidores ou CPUs extras podem ser do mesmo tipo utilizados atualmente (ou de qualquer tipo compatível).

O escalonamento também acontece mais rápido, já que nada precisa ser importado ou reconstruído.

Existe, no entanto, uma ligeira mudança na velocidade. O software com escala horizontal é limitado pela velocidade com que os servidores podem comunicar.

A diferença não é suficientemente grande para ser notada pela maioria dos utilizadores, no entanto, e existem ferramentas para ajudar os programadores a minimizar o efeito. Como resultado, a escalabilidade é considerada uma solução melhor quando se constrói aplicações escaláveis.

Guia para Construir Sistemas Altamente Escaláveis

É mais barato e mais fácil considerar a escalabilidade durante a fase de planejamento. Aqui estão algumas das melhores práticas para incorporar escalabilidade desde o início:

Utilizar software de balanceamento de carga

O software de balanceamento de carga é crítico para sistemas com infra-estrutura distribuída (como aplicações com escala horizontal).

Este software usa um algoritmo para distribuir a carga de trabalho pelos servidores para garantir que nenhum servidor fique sobrecarregado. É uma necessidade absoluta para evitar problemas de desempenho.

Precisa de localização

Software escalável faz o máximo possível perto do cliente (na camada de aplicação). Reduzir o número de vezes que aplicativos precisam navegar no tráfego mais pesado próximo aos recursos centrais leva a velocidades mais rápidas e menos estresse nos servidores.

Edge computing é algo mais a ser considerado. Com mais aplicativos que exigem recursos intensivos, manter o máximo de trabalho possível no dispositivo diminui o impacto de áreas de baixo sinal e atrasos na rede.

Cache onde possível

Cuidado com as preocupações de segurança, mas o cache é uma boa maneira de evitar ter que executar a mesma tarefa repetidamente.

Lider com API

Os usuários se conectam através de uma variedade de clientes, portanto, liderar com API que não assumem um tipo específico de cliente pode servir a todos eles.

Processamento assíncrono

Refere-se a processos que são separados em passos discretos que não precisam esperar que o anterior seja completado antes do processamento.

Por exemplo, a um usuário pode ser mostrado um “enviado!” enquanto o e-mail ainda está tecnicamente processando.

O processamento assíncrono remove alguns dos gargalos que afetam o desempenho de softwares de larga escala.

Limite o acesso simultâneo a recursos limitados

Não duplique esforços. Se mais de um pedido pede o mesmo cálculo a partir do mesmo recurso, deixe o primeiro terminar e use apenas esse resultado. Isto adiciona velocidade enquanto reduz a tensão no sistema.

Utilizar um banco de dados escalável

Bases de dados NoSQL tendem a ser mais escaláveis que o SQL. SQL faz operações de leitura em escala suficientemente bem, mas quando se trata de operações de escrita entra em conflito com restrições destinadas a reforçar os princípios ACID.

Scalar NoSQL requer uma adesão menos rigorosa a esses princípios, então se a conformidade com o ACID não é uma preocupação um banco de dados NoSQL pode ser a escolha certa.

Considerar soluções PaaS

Plataforma como um serviço alivia uma série de problemas de escalabilidade, uma vez que o provedor PaaS gerencia a escalabilidade. O escalonamento pode ser tão fácil quanto atualizar o nível de assinatura.

Leia para FaaS

Função como um serviço evoluiu do PaaS e está muito relacionado. A computação sem servidor fornece uma maneira de usar apenas as funções que são necessárias a qualquer momento, reduzindo as demandas desnecessárias na infra-estrutura back-end.

FaaaS ainda está amadurecendo, mas poderia valer a pena procurar uma maneira de cortar custos operacionais enquanto melhora a escalabilidade.

Não se esqueça da manutenção

Configurar software para testes e manutenção automatizada para que, quando crescer, o trabalho de manutenção não fique fora de controle.

Build with An Eye to the Future

Prioritizar a escalabilidade prepara o seu negócio para o sucesso. Considere-o cedo, e você vai colher os benefícios da agilidade quando ela for mais necessária.

Você está procurando por um software que possa crescer com sua empresa? Marque um encontro gratuito com um de nossos desenvolvedores para falar sobre onde você precisa ir e como podemos levá-lo até lá!