Aqui no escalabilidade sempre estamos abertos as novas tendências em tecnologia. Estamos acompanhando os bancos de dados não relacionais (NoSQL) desde o seu surgimento. Se você não sabe do que estamos falando leia nosso post introdução ao nosql.

Uma grande preocupação de muitos entusiastas do assunto é evitar que todo este hype crie confusões desnecessárias. Percebo que os melhores desenvolvedores que eu conheço que estão utilizando NoSQL, não o fazem puramente pelo hype e sim para resolver um problema específico nas suas aplicações. Mas como toda novidade o NoSQL está envolvido em muito hype, e tem muita gente que se diz guru no assunto mas sabe apenas repetir buzz words sem entender o significado delas. Pensando nisto um grupo de desenvolvedores fez este divertido video :

No dia 18/09/2010 a Locaweb sofreu um ataque realizado por um cracker, conhecido por iSKORPiTX, que modificou a conta de milhares de clientes. O número correto ainda não foi divulgado, porém segundo fontes não confiáveis foram 8 mil sites. As contas modificadas tiveram sua home alterada e todas elas passaram a mostrar uma imagem conforme abaixo:



O que foi modificado?

Qualquer arquivo que tenha no nome algo como: “home”, “default” e “índex”. Exemplos: índex.htm, índex.php, default.html. Se sua conta foi atingida verifique esses arquivos pois provavelmente estão contaminados. Caso tenha backup, apague-os e restaure os arquivos corretos.

Nenhum cliente reclamou de modificações em bancos de dados ou e-mails. Ao que parece o problema ocorreu somente nestes arquivos mesmo.

O problema atingiu os servidores Linux da empresa. Nosso foco no escalabilidade não é segurança da informação mas como qualquer um de nós pode estar sujeito a este tipo de incidente compilamos algumas dicas para te ajudar a evitar que problemas como este aconteçam com seus servidores.

Segurança em servidores Linux

Bem configurado, o Linux é conhecido pelo seu histórico de alta segurança e confiabilidade. O problema é esse histórico favorável dá uma falsa sensação de segurança. A conseqüência desta falsa sensação de segurança é que muitos sysadmins assumem um comportamento de risco deixando vários serviços ativos, usando senhas fracas ou mantendo um servidor desatualizado.

Principais ações para manter um servidor seguro

Não forneça acesso SSH a usuários

Esta atitude parece exagerada e é polêmica, porém para maior segurança no servidor é necessária. Um cracker com acesso à linha de comandos (mesmo que restrita) já percorreu metade da invasão.

Menos é mais

Não instale software desnecessário, tenha instalado somente o que realmente é requisito e necessário para os serviços. Não dê permissão a mais a usuários que não necessitam.

• Nunca mantenha instalados programas compiladores como “gcc” e “gcc-c++”;
• Procure não permitir que qualquer usuário execute programas como “scp” e “wget” (permissão 750). Estes programas normalmente são utilizados para copiar arquivos de outros servidores;
• Jamais utilize permissão 777. Normalmente 755 para diretórios e 644 para arquivos é o suficiente.

Firewall

A regra do “menos é mais” também é válida aqui, configure o “iptables” para fechar todas as portas e permitir somente o que realmente for necessário.

SSH

Este serviço merecia um artigo à parte. Ele é tão importante para a segurança que a primeira atitude pós-ataque da Locaweb foi fechá-lo para todos os usuários. Não há como eu abranger tudo aqui, porém informo as principais configurações:

• Não permitir login de root: Isso torna obrigatório que o usuário faça login no servidor e somente depois faça login como root (su -)
• Modificar a porta padrão: Como a porta padrão é bem conhecida (22), muitos crackers monitoram essa porta na tentativa de realizar invasão pelo serviço. Modifique-a para uma porta maior que 1024, por exemplo, a porta 5544;
• Bloqueie invasões “brute-force”: Para invadir utilizando “brute-force” ou “força bruta” o cracker fica testando milhões de usuários e senhas diferentes. Se o servidor permitir após billhões de tentativas o cracker conseguirá invadir. Utilize programas como BFD (Brute Force Detection) para barrar esses ataques.

Atualizações

Qualquer distribuição que se preze tem suas atualizações periodicamente sempre que uma falha é descoberta. Mantenha seu servidor sempre atualizado para que falhas conhecidas não seja exploradas em seu servidor.

Conclusão

Qualquer corporação hoje está sujeita a problemas envolvendo segurança. Corporações de renome e alta tecnologia (como a NASA) já sofreram desse mal. A internet é um ambiente extremamente hostil e o anonimato torna esses crimes algo impune.

No entanto pequenas mudanças de comportamento (de sysadmins e usuários) podem dificultar e tornar “inviáveis” algumas invasões.

O tema “segurança” é extenso e complexo. O objetivo do artigo não era esgotá-lo, somente noticiar o problema ocorrido e fornecer dicas simples e poderosas para alguns sysadmins desavisados.

Observação final:

Nenhuma das informações no texto sobre a invasão é oficial, elas foram baseadas nos diversos relatos de clientes nas redes sociais e blogs. Os pronunciamentos oficiais até o momento a respeito do ocorrido foram esses:

http://twitter.com/locaweb/status/24799625402

http://statusblog.locaweb.com.br/2010/09/17/alteracoes-indevidas

Após o ocorrido, houve diversas discussões entre Locaweb e Red Hat sobre quem era o “culpado” pelo problema de segurança. A conclusão sobre a discussão pode ser encontrada aqui:

http://blog.locaweb.com.br/archives/5712/comunicado-2/

Uma estratégia que já se consolidou no mundo da internet são o uso de APIs para expandir as capacidades de um produto. Inclusive aqui no Brasil já temos iniciativas neste sentido. Exemplos como o Twitter, Facebook, Google Maps e Youtube, que tem comunidades desenvolvedores bem ativos, inspiram muitas startups a criar seus próprios ecossistemas. Mas para cada um destes exemplos existem milhares de startups que falharam miseravelmente ao criar suas APIs e plataformas. Primeiro vamos aos erros mais comuns na hora de criar uma API :

Não tratar sua API como um produto

Muitas empresas criam uma API como subproduto e a deixam a deriva, esperando que milagrosamente uma multidão de desenvolvedores vai bater na porta. Mesmo que sua API seja um subproduto de outro projeto trate-a como se fosse um produto independente.

Documentação ruim

Desenvolvedores são seres super ocupados e na maior parte dos casos loucos por eficiência. Se eles forem demorar horas para achar o que querem na sua documentação eles vão procurar uma alternativa, muitas vezes dos seus concorrentes. A vida de desenvolvedor já é difícil sem sua documentação confusa para atrapalhar.

Não criar uma sandbox

APIs muitas vezes exigem que os desenvolvedores se registrem para receber algum token de autenticação ou para colocar formas de pagamento. Se sua API exige esforço do desenvolvedor antes que ele tenha oportunidade experimentar cria uma sandbox. Uma sandbox é um local onde os usuários da sua API podem fazer testes com parâmetros e respostas sem ter que se preocupar com demais burocracias. Vai ser neste lugar que os seus desenvolvedores vão aprender sua API sem se preocupar em ter que pagar uma conta milionário no final do mês.

Não colocar a API em domínio separado da aplicação

No inicio pode ser que sua API esteja até na mesma máquina que sua aplicação. Isto não é o mais recomendado mas muitas startups fazem assim. Se você vai mesmo colocar tudo junto pelo menos coloque em domínios separados. Isto vai te dar maior tranquilidade na hora de escalar independentemente sua api. É melhor ter um api.myservice.com do que um myservice.com/api

Não ter um gerenciamento de comunidade

Sem uma comunidade de desenvolvedores dispostos a ajudar ums aos outros sua api está fadada ao fracasso. Criar uma comunidade exige tem e atenção. Um grupo de desenvolvedores dificilmente vai se juntar em torno de sua API sem um esforço muito grande da sua parte primeiro. Crie foruns, blogs, comente, responda, interaja enfim seja humano.

Não esperar mal comportamento

Alguém vai tentar quebrar sua API. Seja por curiosidade, seja com intenções criminosas esteja preparado para mal uso da sua API . Mantenha um sistema de monitorando constante para evitar surpresas desagradáveis.

Não tratar sua API como uma oportunidade de negócios

Sua API pode se tornar o principal produto da sua empresa. Permitir que outros criem algo a partir da tecnologia e produtos da sua empresa pode gerar um efeito em cascata maior do que o efeito original de seus produtos e serviços. Não descarte a possibilidade de sua API no futuro ser o maior driver de uso da sua plataforma.

Escalabilidade Horizontal (scale out), significa adicionar mais nós ao sistema, tais como adicionar um novo servidor e um sistema de software que permita a distribuição do trabalho entre múltiplas máquinas.

Na escalabilidade vertical aumentamos o poder do nosso hardware para aumentar nossa capacidade de lidar um número maior de requisições ou processar uma quantidade maior de informações. Quais as vantagens desta abordagem ?

* Mantemos o mesmo código e configurações do sistema

* Custo de desenvolvimento praticamente zero.

Eu recomendo fortemente que primeiro você tente escalar seu sistema verticalmente. Em muitos casos aumentar para uma máquina maior resolve o seu problema perfeitamente.  Mesmo em sistemas de Cloud Computing como o Amazon EC2 é possível escolher maquinas mais poderosas. Então a dica é que enquanto o seu custo não for proibitivo continue jogando hardware no problema, na maioria dos casos vai ser mais barato que mobilizar o seu time para escrever novamente sua aplicação ou adapta-la para um ambiente distribuído.

Se o seu sistema continua crescendo o preço de continuar fazendo upgrade no seu hardware vai se tornar cada vez maior o que na maioria dos casos vai te obrigar a procurar uma solução distribuída. Sendo assim, deveríamos começar nosso sistema como um sistema que facilmente poderia ser escalado horizontalmente quando necessário certo ? O problema desta abordagem é que muitas vezes não sabemos inicialmente qual vai ser uso real de uma aplicação que vai levar a esta necessidade. A maioria dos projetos muda muito ao longo da sua vida e não temos muita informação no momento inicial de quais serão as necessidades reais no futuro.

Concluindo: Você só vai saber realmente qual a necessidade de escalar seu projeto a medida que ele for crescendo. Por isto cuidado ao otimizar prematuramente seu sistema, pode ser um tiro no pé.

Possuir uma API já deixou de ser um diferencial há muito no mercado americano. Todos esperam que aplicações web permitam que seus usuários exportem e acessem seus dados de maneira mais livre possível. Muitas APIs como a Google Maps, Twitter e Facebook podem ser consideradas como parte da infraestura de muitas novas startups.

No nosso post anterior publicamos a pesquisa do Mauricio Maia sobre os provedores de infraestrutura usados pelas startups brasileiras. Precisamos lembrar que para possuirmos um ecossistema maduro no Brasil precisamos que as startups bem sucedidas sirvam de base para inovações ou seja precisamos que nossas startups também sejam parte da infraestrutura da nossa web.

Compilamos uma pequena lista com startups brasileiras que possuem APIs :

MOIP
API para pagamentos digitais.

Boo-Box
Publicidade online.

migre.me
Encurtador de url

BlogBlogs
Agregador de blogs

Videolog
Video online

Buscapé
E-commerce.

Esperamos que esta lista cresça ao longo do tempo a medida que o ecossistema de startups no Brasil se fortalecer.

Vocês estão usando APIs de startups brasileiras em seus projetos ?

Uma falha no fornecedor de hospedagem (assumido publicamente) tornou-se um grande desastre para o Migre.me e acabou sendo resolvido parcialmente por seu fornecedor anterior.

O ReadWriteWeb abordou muito bem as responsabilidades do fornecedor e o que você pode (e deve) fazer para evitar uma situação parecida, não deixando a redundância para depois.

Mas quais são os fornecedores das principais startups e projetos web brasileiros? A quem estas empresas estão confiando sua infraestrutura, seus dados e até sua reputação?

Fomos atrás das respostas, veja o resultado:

Web Hosting
LocaWeb e Amazon são as escolhas mais comuns nos projetos analisados, seguidos por The Planet, SoftLayer, DreamHost e Rackspace.

Email
A grande maioria está confiando seus emails ao Google Apps.

Veja outras categorias e tabela completa da análise

Update Gráfico de barras:

Na 4a edição do The Developer’s Conference, que acontece em São Paulo nos dias 20, 21 e 22 de Agosto de 2010 teremos pela primeira vez uma trilha exclusiva para NoSQL. Cada trilha é praticamente um evento independente, e está sendo organizado por um parceiro especialista com o apoio da Globalcode.

A trilha noSQL será uma grande oportunidade para falar, conhecer e discutir sobre as diferentes abordagens NoSQL. Haverá diversas palestras com exemplos práticos, demonstrações e cases.

O organizador da trilha é o Alexandre Porcelli que já realizou este ano o primeiro Encontro noSQL Brasil. Porcelli tem trabalhado junto a comunidade de desenvolvedores no Brasil para evangelizar os conceitos e tecnologias noSQL.

Eu estarei no evento realizando uma palestra sobre Big Data, quem quiser bater um papo e trocar algumas experiências eu estarei por lá.

PROGRAMAÇÃO

08:30 às 09:00 Credenciamento e recepção dos participantes com café da manhã
09:00 às 09:50 Abertura
10:00 às 10:50 noSQL: Perdas & Ganhos por Mauricio De Diana
11:00 às 11:50 NoSQL dev_ops #fail? por John D. Rowell
12:00 às 12:50 RestMQ – Message Queue com NoSQL por Gleicon Moraes
12:50 às 14:20 Intervalo para almoço livre
14:20 às 15:10 Graph Databases por Alexandre Porcelli
15:20 às 16:10 A era do Big Data:Explorando oportunidades na era da abundância de dados por Edmar ferreira
16:10 às 16:40 Coffee-break & networking
16:40 às 17:30 Case: Youtube Audio Finder usando Cassandra por Vladimir Moreira Rocha
Case: Topical – Geolocalização com MongoDB e Rails por Maurício Maia
Case: Redis na boo-box por Felipe Vieira
17:40 às 18:30 Case: Persistência Polyglotav por Luiz Fernando Teston
Case: noSQL na BIREME/OPAS/OMS: 20 anos de experiência por Luciano Ramalho
Case: Adotando noSQL no ambiente corporativo do SPC por Júlio Orestes Viegas
18:30 às 19:00 Encerramento e sorteios

Já faz algum tempo que membros do time do @Escalabilidade utilizam a Amazon Web Services (e também da Rackspace, Slicehost entre outros…). E uma dúvida que percebemos que as pessoas sempre buscam sanar é entender como transformar os preços on demand dos serviços da AWS em custos estimáveis, mensais e em reais(R$). Cansados de procurar, criamos uma planilha onde juntamos gastos de EC2, S3, EBS, Data Transfer  e os demais serviços da Amazon, que serve para que qualquer pessoa, com os dados das suas necessidades específicas de infra estrutura consiga simular seus custos de maneira simples.
O resultado você confere no link abaixo e também pode fazer o download aqui.

Para simular, basta preencher os campos em amarelo (número e tipo de instâncias, espaço utilizado em S3 e EBS, volume de data transfer e cotação do dólar).
Vale lembrar que o propósito da planilha não é ser a solução definitiva, então caso queiram propor melhorias, fiquem a vontade para editá-la, atualizá-la e lembrem-se de compartilhar os resultados conosco, em um modelo “open source”. Caso tenham alguma sugestão ou sintam falta de algo, vocês também podem deixar nos comentários as suas sugestões e em breve atualizamos o template.
Esperamos que seja útil!

O Hadoop cresceu de um pequeno subprojeto para um grande framework para computação distribuída em poucos anos. No nosso post anterior contamos um pouco da história do Hadoop e agora vamos entender como o projeto é organizado hoje em dia.

O projeto Hadoop é hoje um projeto independente dentro da hierarquia de projetos da fundação Apache. Durante muito tempo ele foi um subprojeto do Lucene mas seu crescimento acelerado e sua grande versatilidade justificaram a sua elevação a TPL (Top Level Project) da Apache.

Os componentes mais conhecidos do Hadoop são seu sistemas de arquivos distribuídos (HDFS) e o MapReduce. Adicionando valor a esta infraestrutura básica muitos outros projetos surgiram. Estes projetos facilitam a utilização do Hadoop assim como adicionam abstrações de alto nível para facilitarem a criação de sistemas mais complexos. Os subprojetos atuais são:

MapReduce
O Hadoop MapReduce é um modelo de programação e framework para criação de aplicações que rapidamente processam vastas quantidades de dados em paralelo através de grandes clusters de computadores comuns.

HDFS
Hadoop Distributed File System (HDFS) é o sistema básico de armazenamento utilizado por aplicações Hadoop. O HDFS cria réplicas de blocos de dados e que são distribuídos no cluster para permitir computações extremamente rápidas.

Hive
Hive é uma infraestrutura de data warehouse construído em cima do Hadoop que provê ferramentas que facilitam a criação de relatórios e a análise de quantidades gigantescas de dados armazenados em arquivos Hadoop.

Pig
O Pig é uma plataforma de processamento de dados em larga escala que possui uma linguagem de alto nível e um “compilador” que transforma scripts feitos nesta linguagem em programas MapReduce.

HBase
É um banco de dados NoSQL distribuído e orientado a colunas. Usa como sistema de arquivos o HDFS e permite tanto processamento de dados em batch utilizando MapReduce como queries online.

ZooKeeper
Um serviço de coordenação distribuído. O ZooKeeper fornece primitivas básicas para construção de sistemas distribuídos.

Chukwa
É um sistema distribuído para coletar e analisar logs dinamicamente.

Ao longo desta série vamos conhecer melhor cada um destes projetos. Siga o escalabilidade no twitter e não se esqueça de assinar nosso feed para acompanhar o restante da série.

Já não é segredo para ninguém que o Hadoop é hoje a plataforma mais sólida para processamento de dados em larga escala. Esta semana ficamos sabendo que a Cloudera está trabalhando em conjunto com a Quest Software para fornecer uma integração dos produtos Oracle com o Hadoop. Isto demonstra mais uma vez que a plataforma está se tornando um padrão para o mercado.

Estes acontecimentos sinalização uma possível “invasão” das tecnologias “Big Data” que surgiram para resolver os problemas de escala da web para o cenário corporativo. Precisamos entender também que o mercado corporativo tem suas próprias regras e que as coisas neste cenário não acontecem da noite para o dia.

A IBM anunciou hoje que o lançamento da sua distribuição do Hadoop. Ela tem uma estratégia bem sucedida de utilização de softwares open source. Recentemente vimos que eles já estavam usando o Hadoop em alguns de seus projetos. O lançamento desta distribuição mostra que a IBM está ficando cada vez mais comprometida com o sucesso da plataforma. O selo de grandes nomes da indústria do software vão dar maior credibilidade ao Hadoop para futuras implementações no setor corporativo.

Hoje temos 3 grandes distribuições do Hadoop sendo utilizadas nos mais variados projetos. A primeira é a distribuição oficial que pode ser encontrada no site do projeto. A Cloudera, empresa de consultoria em Big Data, tem sua própria distribuição que também é Open Source. O Yahoo também disponibiliza a versão que eles utilizam para a comunidade de desenvolvedores. Com a chegada desta nova distribuição vamos ter uma maior diversidade na comunidade de desenvolvedores e usuários do Hadoop.