Desde de 2009 que trabalho com metodologias ágeis de desenvolvimento de software. Por muito tempo trabalhei com Scrum, que é uma poderosa ferramenta, mas eu sentia que apesar de ser menos prescritiva que RUP ou XP o Scrum ainda tinha algumas prescrições que não se adequavam mais com o processo de trabalho que eu vinha construindo.

Isso ficou bastante evidente quando entrei na Quatix, uma empresa pequena, com uma carteira pequena de clientes, mas que precisava reagir rapidamente as mudanças, para poder se manter na frente dos concorrentes. Venho a alguns meses estudando sobre Kanban, e como seria a melhor forma de empregar essa metodologia que ao mesmo tempo que é muito simples, é também muito poderosa.

O Kanban é a mais adaptativa das metodologias, se aproxima bastante do “faça da forma que você quiser”, e é isso que me seduz. Ela prescreve somente 3 regras:

• Visualize o fluxo de trabalho
• Limite o trabalho em progresso
• Acompanhe o tempo de execução das histórias

Estas 3 regras, ao longo de um processo empírico de experimentações, que deve ser executado todo o tempo através de feedbacks e avaliações constantes do próprio sistema de desenvolvimento, podem ser aliadas a novas regras construídas com o time, transformando o Kanban em um processo totalmente voltado para suas necessidades.

Estamos começando a implantar o Kanban na minha empresa, e montei um workshop para poder apresentar essa ferramenta para todo o time. O que foi mais interessante é que durante a apresentação, diversas discussões e questionamentos foram surgindo, sobre como poderíamos adequar esse processo a nossa maneira de trabalhar, e o legal é que eu não sabia responder, e nem precisava.

Em times auto-organizáveis, essas respostas são criadas e discutidas o tempo todo por todos, as pessoas são fundamentais nesse processo, e é dessa forma que o “seu” Kanban é construído. Estou bastante empolgado em dar prosseguimento a esse “experimento” e ver o quão longe nosso time pode chegar! Aproveito para compartilhar com vocês a apresentação que fiz.

Somos uma empresa de tecnologia com espírito altamente inovador e empreendedor. Trabalhamos com grandes companhias, que confiam no nosso trabalho e nos vêem como verdadeiros parceiros, capazes de aliar o mais alto padrão de tecnologia da informação as suas necessidades.

Trabalhamos com práticas ágeis de desenvolvimento, em um ambiente seguro, altamente colaborativo, que possibilita maior integração e sinergia entre todos da equipe. Acreditamos que o maior valor que uma empresa pode ter está nas pessoas que a constituem, por isso, procuramos valorizar nossos profissionais e dar todas as condições necessárias para seu crescimento pessoal e profissional.

Acreditamos que desenvolvimento de qualidade se faz com profissionais de qualidade, motivados, com toda uma estrutura a seu dispôr, com um ambiente saudável, divertido, e com um processo de trabalho voltado para a realidade do nosso dia a dia.

PERFIL

Nós não procuramos um currículo recheado de títulos, cursos e antigas experiências profissionais. Procuramos uma pessoa que entenda nosso espírito de trabalho colaborativo, onde se manter em contínuo aprendizado é mais importante do que qualquer graduação. Nós queremos pessoas proativas, que saibam e principalmente gostem de trabalhar em equipe. O dicionário traduz equipe como um grupo de pessoas que trabalham juntas para alcançar um objetivo em comum, e é isso que nossa equipe faz, trabalha de forma integrada para produzir a melhor experiência para nossos clientes.

REQUISITOS

Nós trabalhamos com as mais variadas tecnologias, e se você conhece alguma delas e tem muita vontade de aprender as outras, nós queremos você. Na Quatix, desenvolvemos a solução de forma completa, desde concepção, arquitetura, implementação, desenvolvimento até configuração de ambientes de produção. Sendo assim, algum requisitos que procuramos no profissional são:

• Orientação a objetos e padrões de desenvolvimento de software
• Code refactoring
• Arquitetura de software
• Conhecer muito bem uma das linguagens de programação (python, php, ruby ou java)
• Facilidade em se comunicar, aprender e ensinar
• Gostar de escrever testes
• Conhecer técnicas ágeis de desenvolvimento
• Conhecimento de sistemas web (HTTP, HTML/JS/CSS, servidores web), infraestrutura e redes
• Conhecer algum banco de dados relacional ou não
• Saber se adaptar as mudanças
• Trabalhar com software livre, contribuindo com a comunidade

CONTATO

Se você acredita que tecnologia se faz com qualidade e prazer, entre em contato conosco através do email rh@quatix.com.br. Teremos o maior prazer em recebê-lo no nosso escritório, na Barra da Tijuca, Rio de Janeiro – RJ, para um conversa.

Ah, fique a vontade para indicar esta oportunidade para seus amigos.

A apresentação na pythonbrasil[6] foi um sucesso, a galera gostou, questionou, foi bem bacana! Os números do cartola assustam um pouco, e as pessoas custam a acreditar no que nós conseguimos fazer com python. A palestra foi motivada em tentar ajudar a galera, que tem problemas semelhantes aos que nós passamos durante o desenvolvimento do CartolaFC.

Existe muito pouco conteúdo falando de performance em aplicações web feitas em python, e no que puder ajudar podem contar comigo! Segue a baixo a apresentação feita, ficou mais legal do que as anteriores que havia feito, o foco mudou um pouco também, tentei explicar como funciona non blocking I/O, event-based servers, e como extrair o máximo disso com ferramentas como nginx e tornado.

Nginx (pronuncia-se engine X) é um servidor HTTP de alta performance com código aberto e totalmente livre. Foi criado em 2002, pelo russo Igor Sysoev, e teve seu primeiro release liberado em 2004. O Nginx é usado em 6.55% (13.5M) dos domínios ativos no mundo, e esse número vem crescendo exponencialmente.

O Nginx é conhecido por ser muito rápido, estável, com uma grande variedade de módulos, com uma configuração muito simples além de consumir poucos recursos computacionais, como CPU e memória. Ele vem sendo utilizado em diversas aplicações, desde de um simples blog pessoal rodando em um VPS com recursos limitados, até aplicações críticas de alta disponibilidade.

Antes de tudo devemos entender como o nginx consegue ser tão performático utilizando-se de tão poucos recursos. Diferente do servidores tradicionais, nginx não utiliza threads para estabelecer conexões. Ao invés disso, ele utiliza uma arquitetura assíncrona, muito mais escalável, orientada a eventos. Isso permite que ele atenda a milhares de conexões simultâneas com pouco uso de memória e cpu. Essa arquitetura orientada a evendos é conhecida como Asynchronous non-blocking I/O e foi concebida em resposta ao The C10K problem.

O Nginx pode ser extendido com um grande variedade de módulos, que devem ser compilados junto com o código principal, antes de serem utilizados. Os mais importantes estão integrados a versão principal, e já podem ser utilizados na instalação padrão, dentre eles destaco: FastCGI, Gzip, Memcached, Proxy, Rewrite, SSI, Upstream.

Principais características do Nginx:

• Entrega de conteúdo estático, index e listagem de diretórios
• Proxy com balanceamento de carga (round-robin ou iphash) com fail-over
• Suporte a servidores FastCGI remotos com balanceamentos de carga
• Compressão com gzip
• SSI com inclusão de arquivos estáticos ou dinâmicos (através de subrequests)
• SSL
• Poderoso proxy cache reverso, com escrita em disco e configuração fácil e eficiente
• Integração direta com Memcache ou Redis

Características avançadas do Nginx:

• Servidores virtuais baseados em IP ou nome
• Suporta conexão keep-alive ou pipeline
• Configuração flexível, com timeouts e buffers
• Recarrega o arquivo de configurações, sem derrubar as conexões ativas
• Página especias de erros HTTP 400-599
• Reescrita, muito eficiente, de URLs com uso de expressões regulares
• Controle de acesso por IP ou password
• Limitação de velocidade para downloads

Arquitetura específica do Nginx:

• Um processo principal com um ou vários workers, que efetivamente manipulam as conexões
• Suporte a diferentes formas de manipulação de sockets assíncrona: kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select and poll
• Suporte a chamadas de sistema sendfile(): sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+) and sendfilev (Solaris 8 7/01+)
• Manipulação eficiente de memória, necessita de somente 2.5M de RAM para manter 10000 conexões keep-alive inativas
• Mínimo de operações de cópia de memória

Vivemos uma era onde os desafios computacionais são enormes, e esse cenário só tende a piorar. Cada dia temos mais gente acessando e se utilizando dos benefícios da internet, e isso aumenta a complexidade das aplicações, tendo em vista que a grande maioria delas terão que ser desenvolvidas para atender milhares de usuários simultaneamente. E é nesse ponto que entra o Nginx, muito mas que um simples webserver, ele possui características e features indispensáveis no desenho de soluções simples, perfomáticas e escaláveis.

Compartilhando a apresentação que fizemos na PUC-RJ, sobre a nova arquitetura do Cartola FC 2010.

Já se foi o tempo em que para se desenvolver uma aplicação web em Python se utilizava o bom e velho mod_wsgi do Apache para servi-lá. Essa arquitetura vem deixando de ser utilizada por não escalar e performar tão bem como soluções que integram application servers escritos em Python com web servers como Apache e Nginx.

No meu último projeto, precisamos implementar uma solução em python altamente performática. Quando entrei nesse projeto a estrutura que definimos como inicial era a tradicional, quando digo tradicional entenda Apache + mod_wsgi. Não tinhamos muita experiência em desenvolvimento focado em performance, e foi bem difícil encontrar cases de sucesso que pudessem nos guiar. Diria que quando decidimos implementar o novo Cartola FC, fantasy game oficial do campeonato brasileiro, em python, entramos em um túnel completamente apagado e sem luz no final, fomos na cara e na coragem, a fim de provar que performance e escalabilidade não estão ligadas a linguagem e sim a arquitetura da sua aplicação.

Após definir que faríamos em python, pelos benefícios que a linguagem trás, começamos a pensar o que seria a arquitetura ideal de uma aplicação web escrita 100% em Python. Como não tinhamos muito tempo, definimos a estrutura tradicional e seguimos em frente no desenvolvimento, sem deixar de continuar pesquisando a melhor solução.

Após algumas semanas de testes com Apache + mod_wsgi, vimos que não chegava nem perto do que queríamos. Precisávamos de uma aplicação que atendesse 3 mil requisições simultâneas, por máquina. O mod_wsgi não chegava nem perto disso, além de travar com frequência. Foi nesse momento que encontrei uma apresentação feita na pycon de 2007, Scaling Python for High-Load Web Sites, que caiu como uma luva para o nosso problema. Por que não utilizar um web server escrito em Python? Pois é, pensei a mesma coisa!

Agora vem a segunda pergunta, qual utilizar? Sem tempo a perder inciamos os testes com o CherryPy, podereso e consolidado Python web server que se mostrou robusto e performático nos testes inciais. Só que como você já sabe, nosso problema principal é performance e como atender muitas requisições simultâneas. Sobre as requisições simultâneas, descobri que não era um problema tão novo, como relatado no The C10K Problem (o problema das 10 mil conexões simultâneas), e percebi que a solução passaria necessáriamente por um web server non-blocking I/O. Aconselho a leitura do post do Akita, que faz uma imersão legal sobre non-blocking.

CherryPy apesar de ser um excelente framework, não era non-blocking e isso representaria um problema para nossas pretenções. Pequisando sobre python web server non-blocking, descobri 2 bem legais, um é o Twisted, e o outro nosso amigo Tornado. Twisted é uma engine de rede escrita em python, com suporte a diversos protocolos e com um web server non-blocking. Ele é bem completo e complexo, talvez por isso a opção pelo Tornado, que é um framework bem enxuto, com um poderoso web server non-blocking e muito simples de ser implementado.

Antes de prosseguir na escolha do melhor python web server, nos questionamos sobre o uso do tradicional Apache. Lembro que começamos com aquela estrutura tradicional, que caiu por terra com o uso de um web server escrito em python, então porquê continuar com o Apache? Ele só serviria para fazer proxy com a instância do servidor da aplicação, isso enquanto tinhamos uma única instância de CherryPy rodando por máquina, agora já temos inúmeras instâncias, e como balancear a carga entre elas? Simples, utilizando o Nginx!

O Nginx foi uma descoberta e tanto, ele é um servidor HTTP, assim como o Apache, só que possui alguns módulos bem interessantes, dentre eles o HTTP Upstream, que faz balanceamento de carga via proxy com o servidor da aplicação. Além de possuir esse módulo, o Nginx é um dos inúmeros servidores escritos para resolver o The C10K Problem, pois implementa non-blocking I/O com uso de epoll event handler. Utilizando Nginx, estaríamos tratando nossas inumeras conexões simultâneas no front end e balanceando a carga entre as instâncias dos servidores de aplicação. Isso melhorou radicalmente nosso desempenho, saimos de 200 conexões simultâneas com apache+mod_wsgi para 3 mil conexões simultâneas, sem consumo de memória e com pouco uso de CPU. Agora já podemos voltar nossas atenções para o application server, que passa a ser o nosso limitante.

Resolvemos então fazer uma implementação com o Tornado e confrontar os resultados dos testes com o CherryPy. Com o CherryPy o throughput não se mantia estável com o aumento no número de usuários simultâneos, além do alto consumos de CPU por cada instância. Já com o Tornado esses números foram animadores, o throughput se mantia linear e estável a medida que aumentávamos o número de usuários simultâneos, além do baixo consumo de CPU e consumo quase 0 de memória.

Nesse momento havíamos definido nossa arquitetura final, quase no quarto mês de um projeto que seria finalizado no seu sexto mês, nada mal! Essa arquitetura contava com 9 máquinas (Intel Quad-Core Xeon 2.5 GHz), cada máquina rodando um Nginx, balanceando a carga entre 7 servidores de aplicação construídos com Tornado, onde cada máquina pode processar 300 R/S (requisições por segundo) que dá 3K conexões simultâneas, pois uma média de 10% das conexões estabelecidas estão realizando alguma operação simultâneamente.

Para quem entrou em um túnel totalmente escuro, acredito que saímos do outro lado com um belo legado de conhecimento e descobertas que pretendo ir compartilhando com vocês. A primeira e mais importante descoberta que fizemos foi essa, performance independe de linguagem. Construa uma boa arquitetura para sua aplicação, e se ela for escrita em python, aconselho utilizar Nginx + Tornado, pois funcionam muito bem juntos. Nos meus próximos posts, irei falar bastante do Tornado e sobre como extrair o máximo dele.

Qualquer dúvida ou sugestão, deixe seu comentário aqui em baixo, terei o maior prazer em respondê-lo.