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.

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.