# Escalabilidade Horizontal ##O que é O jargão do momento é o Cloud. A nuvem. Pessoas diferentes, empresas diferentes, produtos diferentes possuem definições diferentes do que é o cloud, de onde começa, onde termina. Diferente do "Cloud", uma definição que todos parecem entender logo de cara é o conceito de escalabilidade. É um conceito bem simples de entender, e difícil de aplicar. Quanto mais escalabilidade, mais chances você tem de crescer e agüentar a carga que vem junto. Sem escalabilidade, você pode ser pego de calças curtas e não dar conta de todo mundo que quer acessar o seu conteúdo, ou consumir o seu produto ou serviço. ##Por quê? Todos nós fazemos software querendo que ele faça sucesso. Mas esse sucesso implica em uma multidão de pessoas acessando o seu site. E essa multidão de acessos pode ser pré-determinada (você aparece em algum programa de TV ou na home de um portal) ou de repente (você viraliza). Independente da forma, ter um site escalável é a diferença entre se estabelecer de vez ou quebrar. Outros fatores como histórico de acessos pode te ajudar a ajustar os recursos de maneira que você não pague a mais por períodos de pouco acesso. ##Diferenças entre escalabilidade horizontal e vertical Existem dois tipos principais de escalabilidade: horizontal e vertical. Não falaremos muito sobre escalabilidade vertical por que não há muito o que falar. Você simplesmente compra hardware mais potente. Existem programadores famosos como Jeff Atwood que [recomendam essa técnica](http://blog.codinghorror.com/hardware-is-cheap-programmers-are-expensive/) e ela faz sentido. Perder dias ou semanas de um ou mais programadores para escrever código escalável é bem mais caro do que comprar um servidor top de linha. O problema é que em algum momento o mais caro dos servidores não vai mais dar conta. Aí chega a hora de pensar em escalabilidade horizontal. Essa é uma solução que já é aplicada por banco de dados, que podem ser configurados em cluster com master/slave, por exemplo. O conceito é simples também: Você tem vários servidores compartilhando carga. ## Soluções prontas Hoje existem diversas soluções robustas para você por o seu site no ar e desfrutar de escalabilidade horizontal. Produtos como [Google Cloud Platform](https://cloud.google.com/products/app-engine/), [Heroku](https://www.heroku.com/) e [JElastic](http://www.locaweb.com.br/produtos/jelastic-cloud.html) gerenciam o seu site, adicionam mais servidores e te livram do trabalho de ter que gerenciar infra-estrutura além de ter que gerenciar o seu produto. Mas *é bem importante que o seu site esteja preparado para escalar horizontalmente antes de sair contratando um serviço*. ## Como deixar o meu site escalável OK, chega de blá blá blá. Vou tentar ser o mais genérico possível e passar conceitos que podem ser checados e aplicados em sites feitos em todas as linguagens. ### localhost é o seu inimigo Imagina que no seu site você recebe uma imagem ou processa alguma informação e guarda ela no disco. Daí você devolve para o usuário em algum outro momento. Isso funciona enquanto você tem um servidor só, mas quando você passa a ter N, você não tem como garantir que um usuário vai entrar na mesma máquina em que o dado foi escrito. Você pode evitar isso utilizando um sistema de arquivos compartilhado, gravando informações em um banco de dados ou utilizando um serviço externo como [Amazon S3](http://aws.amazon.com/s3/) ### Cache Ter bastante gente acessando a mesma página vai fazer com que você gere os mesmo dados de novo e de novo e de novo. Caching do lado do servidor é uma alternativa para isso. Se os seus servidores compartilharem um cluster de [Memcached](http://memcached.org/) a sua carga além de ser distribuída, será diminuída por que o primeiro que gerar a página grava, e os outros só repassam a informação já gerada. Caching é um tema interessante, mas falar sobre ele pode gerar um artigo completo por si só. ### Banco de dados Soluções de PaaS prontas normalmente cuidam de escalabilidade de bando de dados para você. Tudo o que você precisa fazer é apontar para o banco de dados que eles te indicam, para o servidor de cache que eles te indicam e pronto. ### Processamento assíncrono Imagine que você precisa gerar um PDF, processar uma planilha, fazer um pagamento de cartão de crédito. E que essas variáveis estão fora do seu controle e podem demorar vários segundos, ou minutos. Segurar uma conexão aberta durante todo este tempo pode ser catastrófico para o seu produto quando se tem um monte de gente na fila querendo fazer outras coisas. Um solução para isso é ter um ou mais servidores reservados para fazer trabalhos assíncronos. No lugar de você receber os parâmetros, processar tudo e devolver logo de cara, você pode receber os parâmetros e enfileirar para isso ser executado no background. O usuário fica com um código ou protocolo e usa para checar o status do processo. Quando o trabalho estiver pronto você libera um link ou atualiza um status em algum registro. A vantagem dessa técnica é que você pode ter uma carga grande que ao invés de você ficar fora do ar, você vai levar mais tempo para processar todos os itens da fila. Cada linguagem e ambiente possui ferramentas específicas para isso. Ruby tem o [Sidekiq](http://sidekiq.org/), Java tem o [HornetQ](http://hornetq.jboss.org/). Outra grande vantagem dessa técnica é que você pode ter o seu site em uma linguagem e os seus workers em outra linguagem. Contanto que eles conversem com a mesma base de dados e/ou os mesmo web-services você fica livre para otimizar/refatorar/re-escrever as partes em separado. ## Links para leitura: * [What does horizontal scaling mean?](http://dba.stackexchange.com/questions/4508/what-does-horizontal-scaling-mean) * [Best Practices For Horizontal Application Scaling](https://www.openshift.com/blogs/best-practices-for-horizontal-application-scaling)