Melhor resposta
Escalável significa que o sistema pode, com relativa facilidade, ser adaptado a uma base de usuários mais ampla do que inicialmente ou originalmente pretendido . Os fatores que determinam a escalabilidade de um aplicativo incluem:
- boa estrutura do programa (quão fácil é o programa de entender e expandir para oferecer suporte a novas funções)
- provisão para múltiplos usuários e acesso e edição simultâneos de banco de dados (para evitar bloqueio de banco de dados, negação de acesso, corrupção ou perda de dados)
- disposições de segurança para acesso de usuário e integridade de banco de dados
- capacidade de funcionar como um aplicativo distribuído em vários servidores e bancos de dados em vários fusos horários
- backup, correção e restauração de banco de dados
- disposições linguísticas e culturais
- provisão para intercomunicação com terceiros aplicativos, expondo uma interface de programa bem gerenciada ou assinando padrões da indústria
- uso de recursos e dependências de hardware / sistema operacional
- desempenho em tempo real
Existem outros fatores, que dependem de domínios de negócios específicos, mas esses são os fatores que vemos rotineiramente se tornarem um i surgem quando uma empresa tenta “dimensionar” ou “estender” seus aplicativos.
A escalabilidade geralmente sofre quando:
- o programa é concebido e escrito por alguém que não hábil nas disciplinas de desenvolvimento de aplicativos
- a responsabilidade por escrever um programa é terceirizada com uma especificação que não explora todos os fatores apropriados para as necessidades futuras dos clientes (uma especificação fraca geralmente leva a soluções não escaláveis )
- não há supervisão de engenheiro de software qualificado que entenda o domínio do negócio
Um exemplo simples de falha de escala é um programa de estoque de armazém no qual trabalhei em 1990 (ish).
O programa original foi escrito para um usuário, um servidor e backups noturnos (durante os quais o sistema estava indisponível). Em ordem sucessiva, o cliente queria:
- aumentar o número de usuários de 1 até 50+ e cumprir várias funções e privilégios de acesso para cada usuário.
- expandir o aplicativo para oferecer suporte a vários armazéns dentro do mesmo país
- expandir o aplicativo para levar em conta os novos armazéns offshore que implicam suporte para vários fusos horários, idiomas, padrões legais e procedimentos operacionais
O programa original nunca foi estruturado para um requisito de escala tão forte. O banco de dados sofreu travamentos freqüentes por “abraços mortais”, perda de dados e tempo de inatividade inaceitável devido a procedimentos de backup do banco de dados. O aplicativo não tinha provisão para entrada de dados “offline” e, claro, não foi escrito para ser tolerante a falhas de problemas de comunicação. Tentar atualizar o programa também provou ser um pesadelo – basicamente, todo o sistema paralisou durante as várias horas que levaram para instalar uma atualização global.
Antes de sermos chamados, como consultores, o programa foi “corrigido” pelo codificador original (singular) que posteriormente saiu e desapareceu de forma inconveniente.
O patch ofuscou a estrutura e funcionalidade do código – no entanto, duvido que o programa tenha sido estruturado ou documentado adequadamente – ninguém sabia o suficiente para perceber o risco que isso representava para a empresa! O código foi escrito em C ++ e usado arrays de bytes em vez de strings de conjunto de caracteres multibyte (MBCS) padrão da indústria … você entendeu!
Fomos chamados para “consertar” o problemas. A verdade é que teria sido mais simples e barato mudar o cliente para um produto de gerenciamento de estoque comercial, no entanto, eles haviam incorporado a modelagem financeira no sistema e ninguém entendia o suficiente sobre como funcionava para transferir esses recursos para um comercial programa (pelo menos sem risco significativo).
No final, apesar de apontar soluções mais econômicas, tivemos que fazer a engenharia reversa do produto e reescrever totalmente o aplicativo. Foram necessários 2 designers de sistema, 4 engenheiros líderes, 20 engenheiros de software, 5 engenheiros de validação e 2 engenheiros de ferramenta / metodologia para reescrever o produto – e quase 2 anos de tempo decorrido para colocar o aplicativo no lançamento geral.
Então como você consegue escalabilidade?
- Comece certificando-se de ter escrito seus requisitos de escalabilidade na especificação do produto. Geralmente a pressão do tempo e o custo mais baixo causarão sacrifícios em áreas que não foram devidamente exigidas na especificação.
- Trabalhe com especialistas no domínio que podem ajudá-lo a desenvolver uma estrutura que atenderá às (prováveis) necessidades futuras.
- Aproveite os padrões de design, bibliotecas, aplicativos 4GL / AI e arquiteturas que foram formulados do zero para evitar problemas de escalabilidade (muitos dos quais foram desenvolvidos a partir de experiências amargas).
- Leia sobre todas as áreas-chave, como bancos de dados distribuídos e tolerantes a falhas para aplicativos altamente concorrentes, arquiteturas de segurança incorporadas, replicação de banco de dados, processamento em nuvem, etc.
- Certifique-se de empregar engenheiros experientes e experientes em posições-chave. Eu diria que quase 50\% dos projetos de resgate que empreendemos foram consequência de engenheiros líderes e projetistas de sistema inexperientes. O resto foi devido a falhas de gerenciamento ou comunicações impróprias entre a engenharia e o cliente.
Então é isso. Hoje em dia, realmente não há desculpa para problemas de escalabilidade em empresas de médio a grande porte; no entanto, muitas empresas começam com apenas um punhado de pessoas que hackear as soluções da melhor maneira possível. Então a empresa cresce e a escalabilidade se torna um pesadelo, em vez da progressão ordenada que deveria ser!
Resposta
A escalabilidade na engenharia de software se refere, normalmente, a projetar sistemas de software de tal maneira que , conforme o número de usuários do sistema aumenta (mesmo por fatores de 100x ou mais), o software continuará a funcionar com tempos de resposta comparáveis. Agora, a próxima pergunta é “como isso é feito?”
O software de desktop independente (por exemplo, jogos) é sempre 100\% escalonável porque cada usuário obtém um computador inteiro para si. Esta é uma forma trivial de escalabilidade.
Os sistemas de software cliente-servidor e baseados na web, no entanto, dependem de servidores , que são computadores que fornecem serviços a vários usuários. Deve ser óbvio que qualquer servidor só pode lidar com um número limitado de usuários simultâneos.
Existem duas técnicas gerais que permitem que um sistema seja dimensionado além do que um único servidor pode lidar. Sistemas altamente escaláveis combinarão as duas técnicas.
A primeira é dividir a funcionalidade em partes diferentes. Uma divisão comum é ter um servidor separado para hospedar o banco de dados do qual o sistema depende (quase sempre há algum tipo de banco de dados para armazenar informações persistentes). O servidor de banco de dados recebe uma grande quantidade de memória e discos muito rápidos ou matrizes RAID, enquanto o outro tipo de servidor precisa de menos memória e relativamente pouco espaço em disco.
Isso pode ser estendido para uma arquitetura de n camadas, onde mais e mais funcionalidades (e dados, para bancos de dados) são divididos entre diferentes processos. Quando a carga aumenta, os processos são migrados para servidores separados para manter o desempenho. Observe que todos esses servidores estão fisicamente no mesmo farm de servidores e conectados por conexões de rede de muito alta velocidade.
A outra técnica usada para escalabilidade é a replicação . Isso significa que, por exemplo, vários servidores da web são usados e cada usuário está conectado a apenas um deles. Para suportar mais usuários, o sistema só precisa de mais hardware (sistemas de servidor da web neste exemplo). Os bancos de dados também são capazes de replicação, de modo que vários servidores de banco de dados podem suportar clones do banco de dados (às vezes é complicado manter as diferentes cópias do banco de dados atualizadas, mas os dbas têm lidado com esse problema há anos) Para sistemas maiores, existem bancos de dados que são projetados para serem escaláveis, distribuindo seus dados por vários servidores.
A2A: “O que significa” escalabilidade “na engenharia de software?”