A segunda edição do evento noSQL Brasil, principal conferência da América Latina sobre o tema, acontecerá em São Paulo nos dias 21 e 22 de Outubro. Este ano o evento conta com uma grade ainda mais rica, abordando não só as tecnologias noSQL, mas também newSQL e Cloud Computing.

Serão dois dias intensos com 12 palestras e 6 Lightning Talks.

Alguns palestrantes internacionais de destaque:

• Alistair Jones, Software Engineer da Neo Technology – empresa responsável pelo Neo4j
• Frank Weigel, Diretor de produtos da Couchbase – empresa responsável pelo desenvolvimento dos populares CouchDB e Membase)
• Benjamin Coverston, Diretor de Operaçōes da Datastax – empresa responsável pelo Apache Cassandra
• Mathias Stearn, Sr. Software Engineer da 10gen – empresa responsável pelo MongoDB

Outros palestrantes importantes também estarão presentes no evento, confira a lista aqui. A grade preliminar já está disponível no site do evento.

O noSQL Brasil será nos dias 21 e 22 de Outubro no Hotel Braston em São Paulo -Rua Martins Fontes, 330 – Consolação.

Os preços promocionais são válidos até o dia 30 de Setembro, então corra para fazer a suainscrição.

O número de soluções de banco de dados com o label “NoSQL” aumentou explosivamente uma vez que grandes nomes como Facebook,Twitter,Linkedin afirmaram fazerem uso dos bancos não relacionais. Mesmo com o crescente número de blogs nobre NoSQL um ecossistema tão complexo precisa de mais do que alguns blog posts para ser aprendido de verdade.

É muito comum recebermos pedidos de bibliografia sobre NoSQL. Resolvemos então compilar uma lista completa de livros sobre nosql para te ajudar em suas pesquisas. Muitos livros ainda estão para serem lançados então é bom ficar de olho nas datas de lançamento de cada um.

MongoDB

MongoDB: The Definitive Guide

Scaling MongoDB

The Definitive Guide to MongoDB: The NoSQL Database for Cloud and Desktop Computing

Cassandra

Cassandra: The Definitive Guide

CouchDB

Beginning CouchDB

CouchDB: The Definitive Guide: Time to Relax

Writing and Querying MapReduce Views in CouchDB

Ainda sendo produzidos :

Redis: The Definitive Guide: Data modeling, caching, and messaging

HBase: The Definitive Guide

Document Design for MongoDB

MongoDB in Action

Scaling CouchDB

Professional NoSQL

Os testes de desempenho são mecanismos extremamente interessantes para uma análise da escalabilidade de um sistema, entretanto em casos mais complexos somente a realização de testes não é o suficiente, para esses casos é necessário realizar uma modelagem de desempenho do sistema computacional como todo.

Modelar o desempenho de um sistema não é simples, mas também não é uma metodologia impossível de ser utilizada. É necessário monitorar, coletar, sintetizar, analisar, otimizar e representar os sistemas com um visão que foge completamente do empirismo.

O objetivo principal da modelagem de desempenho é aproveitar ao máximo do investimento de infra-estrutura de TI, focando na melhoria continua do desempenho dos sistemas. Muitos profissionais acreditam que uma simples otimização de um código fonte do software é sempre a solução para esses casos, outros acreditam que a solução sempre é a troca excessiva dos dispositivos de hardware, ambas as soluções podem ser consideradas na maioria das vezes como soluções paliativas.

A solução está no ambiente do sistema computacional

A verdade é que essas e outras soluções paliativas surgem pela falta de uma visão mais ampla das coisas. É necessário elevar o nível de abstração para entender que as raízes dos problemas de desempenho nem sempre estão relacionadas há um ponto focal básico como o código fonte e sim há um ambiente do sistema computacional como todo. Esse ambiente basicamente pode ser divido em dois: ambiente de usuários e o ambiente de hardware propriamente dito.

O ambiente de usuários é formado por pessoas ou outros sistemas que são capazes de gerar carga de trabalho através das requisições, transações ou processos do software utilizado. O ambiente de hardware é formado pelo conjunto de dispositivos que processam a carga de trabalho gerada pelo ambiente de usuários. O parâmetro utilizado para avaliar a capacidade de um sistema é a análise do nível de serviço prestado pelo mesmo.

Existem várias técnicas que são utilizadas para modelagem e análise do desempenho de um ambiente do sistema computacional, como por exemplo, o modelo de regressão linear. No mercado de trabalho, o profissional que possui conhecimento dessas técnicas é extremamente valorizado, principalmente em grandes companhias que investem uma enorme fatia de seu orçamento em infra-estrutura de hardware, como no caso dos mainframes.

Conclusão

A idéia desse post  foi passar uma visão simplificada da modelagem de desempenho, caso solicitem via comentário, eu posso entrar em mais detalhes de como isso é aplicado no mercado e também em detalhes das técnicas envolvidas para aplicação da mesma.

Segurança da informação não é um dos temas abordados aqui no escalabilidade, mas ocasionalmente a pedido de alguns leitores abordamos alguns tópicos. Recentemente a possibilidade de se roubar a senha de usuários de serviços famosos como o Facebook e o Twitter usando apenas um plugin para firefox causou bastante barulho na comunidade de desenvolvedores.

O Firesheep é um programa que permite o “seqüestro” de sessões em diversos sites, entre eles Facebook e Twitter. Isso significa que se um usuário acessar sua conta no Facebook em uma rede wireless aberta (normalmente redes públicas), o atacante consegue “seqüestrar” sua sessão e acessar sua conta.

O programa é uma extensão para o navegador Firefox e atualmente pode rodar no Windows e no Mac. O objetivo do projeto é forçar que sites como Twitter e Facebook melhorem sua segurança, porém está sendo usado por diversos “I-wanna-be” hackers para roubar as contas de muitos usuários leigos.

Firesheep funcionando (em inglês):

Como se proteger?

ForceTLS

Com a extensão ForceTLS para o Firefox, é possível configurar sites onde é obrigatório o acesso via HTTPS. Acessando o Facebook com HTTPS, faz com que toda a troca de informações seja criptografada. Desta forma o Firesheep não consegue “entender” e nem utilizar sua sessão.

Primeiro instale o ForceTLS no Firefox e após isso configure os sites que devem ser acessados somente com HTTPS.

BlackSheep

Outra opção para se proteger do Firesheep é o BlackSheep também é uma extensão para o Firefox e serve para detectar o Firesheep. Pode ser considerado como um “anti-Firesheep”.

Esta extensão consegue perceber quando o Firesheep tenta seqüestrar a sessão e nesse momento envia um login (na verdade um cookie) falso que engana o Firesheep. Ele avisa o usuário do ataque, informa o IP do atacante e sugere que seja realizado logoff nos sites.

O BlackSheep reaproveitou boa parte do código do Firesheep. Por isso não é possível utilizar ambos (BlackSheep e Firesheep) ao mesmo tempo.

Um vídeo (em inglês) do BlackSheep funcionando:

Caso conheçam soluções para outros navegadores, informem nos comentários.

O genoma humano foi uma das maiores conquistas recentes da ciência. O projeto foi fundado em 1990, com prazo de conclusão de 15 anos . James D. Watson, na época chefe dos Institutos Nacionais de Saúde dos EUA, assumiu inicialmente a direção do projeto. Em 1990, o PGH tinha o envolvimento de mais de 5000 cientistas, de 250 diferentes laboratórios, que contavam com um orçamento, segundo diferentes fontes, que variou de US$ 3 bilhões a US$ 53 bilhões. Em 14 de abril de 2003, um comunicado de imprensa conjunto anunciou que o projecto fora concluído com sucesso, com o sequênciamento de 99% do genoma humano com uma precisão de 99,99%.

Empresas como a 23andme estão em uma nova corrida do Genoma. O desafio agora é desvendar os segredos do genoma de cada indivíduo para poder prever futuros problemas de saúde um dos primeiros passos para uma medicina personalizada. O 23andme não realiza um sequenciamento completo do genoma, mas foca em partes importantes que podem revelar doenças. O serviço tem uma infraestrutura computacional intensiva e um dos seus maiores investidores é o Google.

Mas que relação existe entre o Projeto Genoma Humano e o Hadoop ? Muitos dos custos iniciais de sequenciar inicialmente o Genoma eram custos computacionais e estes custos cairam significativamente ao longo dos anos. A facilidade de usar ferramentas Big Data como o Hadoop vai permitir que um número muito maior de descobertas sejam feitas explorando os dados gerados pelo sequenciamento de DNA. Quem nunca parou para pensar que nossos smartphones de hoje são tão poderosos quanto os nossos desktops de antigamente ? O barateamento do poder computacional vai provocar impactos muito maiores do que video games mais poderosos e computadores menores.

Segundo estimativas do National Human Genome Research Institute o custo total de sequenciar o genoma humano vai cair para $1000 até 2014 e segundo alguns especialistas pode chegar até $100. Este barateamento vai gerar uma explosão no volume de dados relacionados ao genoma e muitas oportunidades.

Estamos sempre falando de Big Data aqui, mas um erro muito comum que é pensar em Big Data apenas como dados de redes sociais e na web. Esta tendência está apenas começando e vamos ver muitas aplicações que vão além do mundo da web.

Nesta palestra interessante do Deepak Singh vemos como aplicar o Hadoop na Bioinformática.

Hadoop for Bioinfomatics – Deepak Singh from Cloudera on Vimeo.

Cloud Computing é um dos assuntos que vem gerando bastante interesse a algum tempo. Aqui no Escalabilidade estamos sempre falando das novidades referentes a Cloud Computing e notamos como existe uma carência muito grande por informações a respeito do assunto. Pensando nisto preparamos uma palestra de introdução a cloud computing que será apresentada no BizsparkCamp em Belo Horizonte.

O evento é uma oportunidade para os novos empreendedores conhecerem a mais recente tecnologia de Computação nas Nuvens (Cloud Computing) da Microsoft: Windows Azure.

Será um momento oportuno para as Startups avaliarem a possibilidade de incorporar as tecnologias de Computação nas nuvens em seus projetos, aumentando o seu diferencial competitivo de mercado.

O BizsparkCamp será seguido de mais duas etapas, Hands on Labs (imersão em laboratório), as empresas interessadas poderão testar os novos aplicativos tecnológicos e Provas de Conceito, análise do cenário das startups para aplicação dos recursos tecnológicos.

DATA:
O evento principal acontece no dia 21 de outubro das 18h00 às 22h30

LOCAL:
Centro de Inovação Microsoft (MIC BH), localizado na PUC Minas unidade São Gabriel

ENDEREÇO:
Rua Walter Ianni, 255 – Bairro São Gabriel

As inscrições devem ser realizadas até o dia 20 de outubro (hoje) pelo site:
http://www.micbh.com.br

Os slides e um resumo da palestra serão publicados aqui no Escalabilidade. A ideia é ser uma introdução geral a cloud computing não se limitando a nenhuma tecnologia em especial. Quais assuntos vocês consideram que são essenciais para este tipo de discussão ?

Projetos de desenvolvimento de software são complexos. Anos de engenharia de software nos ensinaram que fazer e gerenciar grandes volumes de código é uma tarefa de grande dificuldade. Um dos motivos pelos quais desenvolvimento de sotware é uma atividade complexa se deve ao fato de ser uma atividade social, sim social. Grandes projetos são construidos pela colaboração de muitos desenvolvedores e os maiores avanços que em metodologias de software nos últimos anos se originam da aceitação de que se queremos melhores softwares devemos prestar maior atenção nas pessoas e não apenas no código.

Uma maneira de entendermos a complexidade envolvida é visualizar a evolução de grandes projetos open source. Os logs de controle de versão são uma mina de ouro de informações para começarmos a entender as interações entre os desenvolvedores envolvidos e os projetos.

Code Swarm é um projeto open source para gerar visualizações de projetos de software pela análise dos logs de controle de versão. veja alguns exemplos:

code_swarm – Apache from Michael Ogawa on Vimeo.

code_swarm – Python from Michael Ogawa on Vimeo.

O code_swarm é compatível com os seguintes controle de versão:

Subversion
CVS
Git
Mercurial
Perforce
VSS
Starteam
Wikiswarm
Darcs

O código está disponível em http://code.google.com/p/codeswarm/

Eu tenho experimentado vários bancos NoSQL desde o surgimento do movimento. Com o sucesso do termo e o seguinte hype, muito bem capitalizado por algumas startups, muitos mitos sobre o NoSQL surgiram e ganharam força. Conversando com alguns desenvolvedores envolvidos com NoSQL aqui e fora do país, decidimos que já era hora de desmistificar algumas dessas afirmações. Escolhemos os mitos mais comuns com relação ao NoSQL :

NoSQL é escalável

Uma das grandes promessas dos bancos NOSQL consiste em dizer que eles são mais escaláveis que os bancos de dados relacionais. O problema com esta mensagem que é vendida por algumas empresas é que ela não é inteiramente verdade. Dizer que seu sistema escala sozinho é vender um sonho. Ele pode até ser mais fácil de escalar se comparado a outras soluções mas ainda sim exigira algum esforço para escalar.

Não precisamos de DBAs

No mundo dos bancos relacionais a figura do DBA sempre está presente. Com sistemas que tem particularidades para cada vendor os DBAs ficam a cargo de instalar, configurar e manter cada banco de dados em suas particularidades. Muita gente diz que quando se trabalha com NoSQL não precisamos de DBAs. Acredito que talvez não no sentido tradicional, mas ainda vamos precisar de alguém responsável por lidar com o banco e com o acesso aos dados. Esta função pode vir a se tornar parte do trabalho de um desenvolvedor ou se tornar a função full time de alguém no seu time que pode ser até um DBA com conhecimentos em NoSQL. Em aplicações reais em produção muito provavelmente será necessário misturar bancos relacionais e não relacionais, possuir alguém que navegue facilmente nos dois mundos em seu time é uma grande vantagem.

NoSQL é mais econômico

Meia verdade. Muitos vendors de NoSQL afirmam que suas soluções vão baratear o custo dos seus clientes. Em parte sim, em algumas situções o custo em usar um banco de dados relacional pode ser proibitivo devido a escala ou a licenças envolvidas. Existem muitos casos entretanto que uma solução relacional atende perfeitamente todas as necessidades do cliente e ainda sim pode ser considerada barata. Bancos de dados open source como MySQL e PosgreSQL são usados sem problemas por um grande número de aplicações com sucesso.

Conclusão

Se você está começando agora com o NoSQL, cuidado para não cair em armadilhas. Sempre interaja com a comunidade, converse com outros desenvolvedores sobre suas experiências reais com NoSQL e não se esqueça de deixar suas dúvidas nos comentários. Se você já possui alguma experiência, quais outros mitos você vê com relação ao NoSQL ?

Um desafio para o mercado de software 

Para milhares de empresas, o seu crescimento no mercado pode ser medido através do aumento da quantidade de usuários de seus sistemas web. Como essas empresas podem ter garantias que os seus sistemas suportam esse aumento significativo de usuários tão desejado por elas?

Imaginem o caso de uma empresa que para conseguir um aumento em sua carta de clientes realiza um investimento em uma campanha de marketing milionária. Basicamente, nessa campanha os produtos seriam vendidos com descontos de 80% caso as compras fossem realizadas no horário de 03h as 04h da madrugada de um determinado dia. Quais seriam os impactos para essa empresa se o sistema não suportar o aumento de carga proporcionado pela campanha e ficasse fora do ar?

Solução eficiente para o problema

A verdade é que existem várias formas de analisar a capacidade de um sistema manter a sua disponibilidade e desempenho esperado, frente a um aumento significativo de sua carga de usuários, ou seja, analisar sua escalabilidade. Uma das formas seria a realização de testes de desempenho e é esse o tema que será abordado neste post.

O teste de desempenho é um processo de emulação das atividades realizadas no sistema e é capaz de:

• Determinar a quantidade de usuários que o sistema suporta;
• Determinar o tempo de resposta do sistema;
• Auxiliar na otimização da configuração do sistema;
• Verificar o desempenho do sistema em diferentes plataformas (Hardware e Software);
• Identificar o comportamento do sistema caso sofra um grande aumento inesperado da carga de usuários;

Tipos de testes de desempenho

Os quatro tipos de testes de desempenho mais utilizados são descritos a seguir:

• Carga: Seu objetivo é validar os tempos de respostas dos processos de negócios e transações críticas em relação ao que foi especificado nos requisitos suplementares do sistema. 
• Volume: Seu objetivo é determinar o throughput de um processo especifico. O termo Throughput possui diversas definições, nesse caso é o número máximo de transações solicitadas ao sistema por uma unidade de tempo. 
• Stress: Seu objetivo é determinar sobre que carga o sistema pode falhar e como ele pode falhar. 
• Longevitude: Seu objetivo é identificar os problemas de desempenho que possam aparecer após o sistema ter sido submetido a um longo período de carga elevada.

A única saída é a automatização

Fazer uma simulação de 1 mil, 10 mil ou 450 mil usuários acessando ao mesmo tempo uma determinada funcionalidade de um sistema somente é factível através da automatização. Existem várias soluções de automatização no mercado para esse segmento, entretanto abaixo estão duas dicas para serem utilizadas durante a definição do modelo de uso dessas soluções: 

• Existem diversos tipos de usuários: Os testes automatizados devem ser realizados simulando todos os tipos de usuários possíveis. Um exemplo de modelagem de usuários é:
  • 50 % dos usuários acessam apenas a home Page;
  • 30% dos usuários navegam por todas as paginas, colocam alguns produtos no carrinho de compra, porém não efetivam as compras;
  • 15% dos usuários navegam em algumas páginas, colocam alguns produtos no carrinho de compra e efetivam algumas compras;
  • 5% dos usuários acessam diretamente a página do produto e efetiva a sua compra; 
• É extremamente recomendado realizar apenas uma variação por vez nas variáveis utilizadas para execução dos testes (carga de usuários, configurações do sistema, base de dados, hardware, entre outros) para comparações e identificações confiáveis dos impactos da mudança.

Conclusão

Para fechar esse post, concluímos que uma das formas eficientes para validar a escalabilidade de seu sistema é o teste de desempenho. Facilmente podemos identificar também que é necessário realizar uma capacitação em toda metodologia que envolve a execução desse tipo de teste automatizado. Para quem deseja conhecer a solução líder de mercado desse segmento, que é comercializada para pequenas, médias e grandes empresas, acesse o site do IBM Rational Performance Tester: http://www-01.ibm.com/software/rational/offerings/quality/performance.html

Programação imperativa, funcional, orientada a eventos e atores. Muitos programadores não conhecem todos estes termos, mas hoje falaremos de um em especial: a programação funcional e o que ela tem a ver com escalabilidade.

Comecemos pela definição de programação funcional:

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state. [Fonte]

Traduzindo temos:

Em Ciência da Computação, programação funcional é um paradigma de programação que trata a computação como avalição de funções matemáticas e evita estado e dados mutáveis. Dá ênfase à aplicação de funções em contraste com o estilo de programação imperativa, que dá ênfase em mudanças de estado.

A maioria de nós, desenvolvedores, estamos acostumados com o paradigma imperativo, presente na maioria das linguagens comerciais de hoje em dia (PHP, C#, Java, C++, etc) e quando vemos um código de uma linguagem funcional, a primeira impressão é um grande WTF?!.

É realmente difícil conceber a idéia que você não tem variáveis para guardar o estado. De fato, em programação funcional, toda variável só pode ser assinalada uma única vez (como const em C++ ou final em Java) e isso reflete a o que a definição diz sobre “evitar mudança de estado”. Em programação funcional, o estado não fica em variáveis, mas na pilha. Isso traz algumas vantagens para o programador:

• Seu código fica mais fácil de testar, já que você precisa testar somente a saída das funções, sem se preocupar com o estado da aplicação ou de um objeto qualquer.
• O debugging é mais fácil, novamente por causa do estado que não necessita ser testado. Se ocorrer uma exceção, é só olhar na pilha e ver o que aconteceu e voilà: todo seu estado estará na pilha!
• Facilita a escrita de programas concorrentes e paralelos, pois não há variáveis compartilhadas e, portanto, não há semáforos, deadlocks ou outros efeitos colaterais.

Opa opa, a última parte é interessante: facilita a escrita de programas concorrentes e paralelos.

Paralelismo e escalabilidade

Paralelismo é a capacidade de sistemas executarem instruções simultâneamente e há uma ligação entre paralelismo e escalabilidade bem importante.

Há alguns anos vimos a entrada de processadores multicore no mercado. A principal razão para isso é que ficou difícil para os fabricantes aumentar a performance de um único processador, portanto, a saída mais óbvia foi aumentar o número de cores em um processador. Com isso, o usuário poderia executar mais de uma tarefa ao mesmo tempo sem que o desempenho de uma interfira no desempenho da outra.

Porém, fazer com que os atuais sistemas consigam aproveitar a capacidade total de processamento de todos os cores de um processador ainda é um desafio. A programação paralela é bem mais complexa do que a programação seqüêncial, principalmente quando há a necessidade de compartilhar recursos.

Aí que a programação funcional entra: como não há recursos compartilhados, escalar uma aplicação escrita em uma linguagem funcional torna-se mais simples do que uma linguagem imperativa. Mesmo que você tenha escrito algo utilizando o paradigma funcional e pensando em uso de processadores single core, seu compilador pode lhe dar uma mãozinha e otimizar seu código pra sistemas multicore.

Sistemas paralelos e distribuídos

Até agora focamos em sistemas paralelos, que são executados em somente uma máquina com vários cores e consegue escalar bem com isso. Com o crescente número de cores por processador, paralelismo torna-se um assunto interessante, porém limitado em alguns casos. E se precisarmos de mais processadores, só que em máquinas diferentes? Como podemos fazer isso?

Bem, talvez aí somente uma linguagem funcional não te ajude muito. Você precisa de uma forma de trocar informações com outros processos/threads em outras máquinas. Como discutimos anteriormente, acesso compartilhado de variáveis não é uma opção. Uma boa opção que nos resta é a passagem de mensagens.

Alto paralelismo, passagem de mensagens e tolerância a falhas: conheçam o Erlang

O Erlang é uma linguagem funcional e orientada a concorrência desenvolvida na Ericsson com o objetivo inicial de servir como linguagem de desenvolvimento de aplicações para telefonia.

Desenvolvimento de aplicações pra telefonia é algo complexo, pois são sistemas que têm que apresentar o mínimo possível de falhas. Imagine sua central telefônica lidando com um deadlock enquanto você tenta ligar por socorro. Se estes sistemas falharem, vidas podem ser perdidas (sem exageros).

A atualização destes sistemas não pode acarretar em downtime. Você não pode simplesmente parar uma central pra fazer o update de um software. Aí que entra uma funcionalidade interessante do Erlang: hot code swapping, que permite a modificação do código sem a necessidade de parar o sistema.

Mas o que torna o Erlang uma linguagem interessante pra quem quer trabalhar com programação concorrente são as construções a nível de linguagem para programação multithread. O Erlang possui uma pequena série de primitivas para criação e comunicação de processos. Não confunda processos do Erlang com processos do sistema operacional ou threads: são simplesmente “processos leves” criados pela VM do Erlang.

Como era de se esperar, a comunicação destes processos é feita através de troca de mensagens de forma assíncrona, sem compartilhamento de estado. Note o destaque da palavra assíncrona: um processo não espera a resposta de outro: ele simplesmente pode continuar executando sem ser “bloqueado”. Não é a toa que os sistemas de telefonia da Ericsson tem um tempo de parada de aproximadamente 31ms por ano

Não é de se espantar o seguinte resultado comparando um servidor Web (Yaws) escrito em Erlang com o Apache:

Os pontos vermelhos representam o comportamento do Yaws, enquanto os verdes e azuis representam o Apache rodando localmente e num sistema de arquivos NFS. Resumidamente, o que o gráfico mostra é que o Yaws conseguiu ter um throughput de aproximadamente 800 KBps e suportar até 80.000 conexões simultâneas, enquanto o Apache morreu em torno das 4.000. Tudo isso graças ao sistema de concorrência do Erlang.

Conclusão

Este post apenas arranha a superfície na discussão sobre linguagens de programação (especialmente as funcionais) e escalabilidade. A nossa intenção é iniciar uma discussão e produzir mais posts falando do assunto. Diga-nos o que achou! Give us your 2 cents

Referências:

http://en.wikipedia.org/wiki/Erlang_(programming_language)
http://www.defmacro.org/ramblings/fp.html
http://bc.tech.coop/blog/050119.html