Vocês podem imaginar que com a quantidade massiva de marcas e conteúdo que a Abril gera, ela representa uma porção importante do conteúdo digital da Internet brasileira. E eles começaram faz tempo a investir em Internet. Nesse período basicamente tudo que vocês poderiam imaginar em termos de gerenciamento de conteúdo já foi experimentado. Estamos falando de Content Management Systems, os famosos “CMS”. Eles já tentaram produtos comerciais, produtos de código aberto, desenvolvimento customizado. Porém, nenhum desses produtos foi pensado para atender a grande escala presente na Abril.
Quando você tem uma empresa focada, seja ela grande ou pequena, a maioria dos CMS provavelmente vai atendê-lo bem. Porém quando você tem dezenas de marcas, cada um com diversos sites, com necessidades bem diferentes de requisitos e ainda precisando de cross-polination, ou seja, reutilizar conteúdo gerado num site em outros, estamos falando de um grande problema.
Existe um grande dilema sobre centralizar o controle do conteúdo ou diversificá-lo de forma autônoma entre as diversas marcas. A primeira opção traz o risco de se escolher o mínimo denominador comum, a segunda traz o problema de reuso do conhecimento, retrabalho entre diferentes sites.
A Primeira Tentativa
A história de Ruby na Abril começa “oficialmente” quando a startup WebCo, fundada pelo nosso conhecido Manoel Lemos, foi integrada à Abril Digital, alguns anos atrás. Antes, a Abril era uma empresa essencialmente voltada a Java e .NET.
Adotar novas tecnologias em empresas que não tem essa cultura é muito difícil, seja qual for o tamanho da empresa. Em particular é difícil em empresas do tamanho da Abril. Significa lidar com cultura, com política. Felizmente a cultura da Abril é muito mais aberta do que a da maioria das empresas que usam tecnologia. Mesmo assim isso significou que muitas pessoas deixaram a empresa. Por outro lado, muitas novas pessoas também entraram. Eu considero que esse tipo de movimento é necessário e inevitável: não se pode salvar todos.
Depois das diversas tentativas de resolver o problema de CMS na Abril, logo no começo da adoção de Rails, com o auxílio da equipe experiente que veio da WebCo, resolveram iniciar um projeto de criar um CMS em Ruby on Rails. A equipe original tinha por volta de 30 pessoas sendo que a maioria ainda era inexperiente na tecnologia.
Imaginava-se que o fato de usar um sistema de controle de versão distribuído (Git), com uma aproximação de projeto de código-aberto onde todo mundo poderia fazer commtis sobre qualquer parte do projeto, facilitaria a evolução do sistema da mesma forma como funciona em projetos de software livre.
Como se poderia prever, o tiro saiu pela culatra. A falta de experiência da equipe, as pressões de prazos e entregas, e principalmente o fato de terem escolhido uma arquitetura monolitica (uma única aplicação “gorda”), levou ao primeiro fracasso.
Mas felizmente a Abril não parece ser do tipo de empresa que usa o fracasso como limitante para adoção de tecnologias e o fracasso virou “lições aprendidas”. Em Outubro de 2009, um novo esforço foi iniciado, mas desta vez com mais planejamento e pesquisa para evitar os mesmos problemas.
A Segunda Tentativa
Considerando tudo que já foi feito e o tipo peculiar de negócio da Abril, a segunda tentativa migrou para um caminho diferente: em vez de desenvolver um único sistema de CMS que concentra todas as regras de negócio de todas as marcas da Abril, decidiu-se por tentar o caminho da arquitetura de Sistemas de Sistemas.
A raíz para isso foi muita discussão conceitual em torno do que se queria com um sistema de conteúdo e o entendimento, justamente, sobre o objeto Conteúdo. É importante saber definir o que está fazendo. E o que foi entendido é que:
“A Abril é uma empresa de mídia, geradora de conteúdo. Conteúdo é a propriedade mais importante da Abril.”
Tendo isso em mente, muitas coisas ficam mais claras. Conteúdo, para a Abril, é puro, sem marcações de estilo, sem HTML misturado. Ela deve estar na sua forma mais limpa. E isso é crucial se você imaginar que além de Internet esse conteúdo amanhã pode ser reaproveitado novamente em outras mídias impressas, em novos dispositivos como smartphones e tablets e para isso ela deve ser o mais flexível possível.
Portanto, o coração desse novo projeto seria um sistema cujo núcleo seria o conteúdo. O segundo entendimento é que seria impossível conciliar todas as regras de negócio e requisitos da empresa em um único sistema.
Se entendi direito, daí temos uma abstração acima do Conteúdo, estão os Domínios, estes sim que concentram regras de negócio específicas de cada site ou cada marca. Um sistema poderia ter um ou mais domínios, que consomem um ou mais Recursos/Conteúdos. E cada sistema poderia interagir entre si.
Para isso seria desenvolvido um sistema principal, uma plataforma de gerenciamento de conteúdo puro e uma forma para que os outros sistemas pudessem consumir esse conteúdo. Daí o conceito de Sistemas de Sistemas. A pesquisa sobre essa idéia naturalmente leva a coisas como SOAP, XML, RPC mas felizmente eles esbarraram nas apresentações de Jim Webber sobre REST.
REST é um conceito crucial nessa nova plataforma, ela seria a implementação que permitiria múltiplos sistemas heterogêneos interagindo entre si. E principalmente a partir do fim de 2009, as discussões sobre uma arquitetura verdadeiramente REST começaram a aumentar, especialmente por causa do livro REST in Practice escrito por Jim Webber, Ian Robinson e Savas Parastatidis, que ainda estava sendo escrito (aliás, recomendo se quiser entender esse assunto mais a fundo).
Com esse conceito fica o entendimento que até agora estávamos usando HTTP de forma errada, meramente como um protocolo de transporte em vez de um protocolo completo de aplicação.
No Brasil, em paralelo a isso, um movimento foi catalisado principalmente por pessoas como Guilherme Silveira, da Caelum, que começou o projeto Restfulie. Esse projeto tem componentes de servidor que transformam o framework Ruby on Rails num ambiente verdadeiramente REST (sim, o Rails não é totalmente REST como se imagina) e também componentes de cliente para conseguir consumir tais recursos.
Eu mesmo tive a oportunidade de colaborar 6 meses atrás, quando ajustei alguns códigos do Restfulie para criar minha apresentação para a RailsConf 2010, apresentado em Baltimore. Minha apresentação se chama Making Rails Really Restful, com o objetivo de iniciar a discussão sobre transformar o Ruby on Rails numa plataforma totalmente Restful. Infelizmente não colaborei tanto quanto gostaria, mas o Guilherme e a Abril continuam evoluindo essa idéia.
A Abril adotou o Restfulie e também colaborou bastante para a evolução desse projeto. Todos aprendemos várias coisas pelo caminho. Por exemplo, o formato que teoricamente é mais compatível com o Restful seria o Atom. Investimos algum tempo criando bibliotecas para suportar isso, porém a falta de boas bibliotecas já existentes para consumir Atom, e a dificuldade relativa de sua especificação, levaram o projeto a adotar Json, um formato muito mais simples tanto de ser gerado quanto consumido.
Não é fácil entender a forma Restful. Mesmo quem está há muito tempo no assunto ainda pode ter dificuldades em alguns aspectos, justamente por não ser muito restritiva, podem existir várias formas de resolver problemas específicos. Mas com o básico implementado corretamente, muita coisa vem sozinha.
Uma das coisas que vem ao se implementar HTTP como protocolo de aplicação é uma separação maior de responsabilidades. Um exemplo disso é o cabeçalho do HTTP sendo usado da maneira correta, trazendo os códigos de resposta corretos (20x para sucesso, 50x para erros, etc) que a aplicação cliente deve usar; trazendo os cabeçalhos de expiração e ETags.
Ao trazer os cabeçalhos de controle de cache, a lógica do cache pode ficar fora da aplicação, numa camada transparente entre o sistema back-end e os clientes consumidores. Sistemas como Varnish tiram vantagem da existência desses cabeçalhos para gerenciar de maneira correta a expiração dos recursos. E cada recurso pode expôr sua própria característica de expiração, que o sistema de cache saberá respeitar. Quando o HTTP é usado apenas como protocolo de transporte, as bibliotecas atuais simplesmente ignoram a geração desses cabeçalhos e isso impede quaisquer sistemas de cache no meio do caminho de conseguir fazer seu trabalho.
Nessa idéia de sistemas de sistemas, já existem múltiplas aplicações que interagem entre si. Dentre alguns dos componentes ortogonais, ou seja, que podem ser usados por diversos sistemas estão o sistema de Search (que implementa Apache Solr como engine, Nutty como crawler, etc) que expõe uma interface Rest também para se consumido. Existe o sistema de autenticação e single sign-on. O usuário que vai editar o conteúdo tem uma interface web de administração e o Web Master, que configura e edita a estrutura dos sites também tem suas próprias ferramentas na forma do Sitetools.
Mesmo se a interface de administração for formada por telas vindas de sistemas diferentes, implementadas em sistemas independentes, o usuário final tem a experiência de estar usando um sistema “monolítico”, porque o single sign-on faz as mudanças entre sites ser transparente, e o cuidado com UX (Experiência do Usuário) e Design, enganam o usuário a achar que continua no mesmo sistema. Pense quando você pula de um Gmail para o Google Reader ou para o Google Docs de maneira transparente, é a mesma coisa.
Esses e outros sistemas, funcionando em conjunto de forma a fornecer conteúdo a outros sites que precisem consumí-lo, forma a plataforma chamada de Alexandria.
Alexandria
Todos conhecem a história da famosa Biblioteca de Alexandria que tentou concentrar todo o conhecimento do mundo e acabou em um grande incêndio. O projeto “Alexandria” também tem por objetivo concentrar todo o conhecimento da Abril, porém ao mesmo tempo “incendiando” os sistemas monolíticos que o precederam e criando um ambiente distribuído de diversidade.
Com uma plataforma como essa, fornecendo serviços na forma de REST, quaisquer novos serviços/sites podem ser criados, gerando um ecossistema de sistemas. Num ambiente heterogêneo como esse, talvez seja realmente a única e a melhor solução.
Além dos arquitetos David e Júlio, a plataforma está sob a responsabilidade de desenvolvimento de cerca de 30 pessoas no total, entre desenvolvedores, gerentes, arquitetos. Mas ao contrário da Primeira Tentativa, desta vez eles estão divididos em cerca de 4 equipes menores com cerca de 5 desenvolvedores cada, favorecendo uma comunicação maior entre seus membros. As equipes se coordenam entre si mais ou menos como um Scrum of Scrums.
A Abril felizmente tenta manter uma cultura aberta de desenvolvimento de software, apesar do seu tamanho corporativo. Por exemplo, eles tem um Open Friday, onde 1 ou 2 sextas-feiras do mês são dedicadas para as pessoas das equipes trabalharem no que quiserem, como melhorias no projeto, novos projetos, experimentações e pesquisas e, no fim do dia, eles se reúnem para discutir no que trabalharam durante o dia. É uma forma de incentivar a experimentação e novas idéias.
Cada equipe trabalha com autonomia na forma da implementação e a arquitetura é responsabilidade dos arquitetos. Porém, nada como o que se imagina tradicionalmente como “Arquiteto de Software”, ou seja, o estilo antiquado da pessoa ou pessoas que detém a autoridade das decisões técnicas mas que raramente tem experiência de verdade com código. Os arquitetos da plataforma continuam tendo a responsabilidade, porém as idéias são discutidas com todos os envolvidos, os arquitetos colaboram com código ou com provas de conceito (e aqui um sistema distribuído de controle de versão como o Git fazem diferença) e eles tentam evoluir o sistema de maneira racional e com bom senso. E em vez de serem “Arquitetos de Software”, tentando ditar coisas inúteis como padrões de código, bibliotecas permitidas e coisas do tipo, eles preferem ser “Arquitetos de Sistema”, mais preocupados em manter a coesão entre os sistemas, de forma que a plataforma não se torne mais um “macarrão” monolítico e altamente acoplado.
A plataforma está em fase Beta, deve entrar em produção até o começo do Ano, em sua primeira versão e a partir daí vai evoluir com mais funcionalidades. A partir daí novos projetos poderão já tirar vantagem do Alexandria e sites legados podem ser migrados, um esforço que deve consumir provavelmente os próximos 2 anos.
Conclusão
A Abril hoje apóia soluções em Ruby e novas tecnologias como Mongo DB e pelo jeito pretende se manter atualizada. Arquitetos, desenvolvedores, gerentes, na sua maioria parece que estão se adaptando bem. E tudo isso é possível porque os shareholders dão seu apoio. Nesse caso vale falar novamente do Manoel Lemos, que é o atual CTO da Abril Digital. Com seu grande background e experiência técnica, ninguém seria melhor para conseguir acelerar a adoção de Ruby em larga escala como foi na Abril.
Fica a dica: sistemas que por natureza englobam múltiplos sub-sistemas que poderiam funcionar de forma separada (ex. ERPs), deveriam ser pensadas exatamente como sistemas independentes que interajem entre si.
Como um exemplo pequeno, mesmo este pequeno blog, que se fosse monolítico não teria nenhum problema, é um mashup de serviços. Por exemplo, o sistema de comentários é do Disqus, os sistemas de carrinho de compra e pagamento são do Pagseguro e Paypal, a monitoração a análise são da NewRelic e Google Analytics, os vídeos ficam no Blip.Tv, e assim por diante. É uma forma rudimentar de aplicação composta por múltiplos sistemas independentes.
A plataforma Alexandria está evoluindo para se tornar a espinha dorsal de todo um ecossistema de conteúdo da Abril, e ela é desenvolvida em Ruby. Seu conceito de sistemas de sistemas é o ideal para um ambiente como esse e é a melhor forma de escalar qualquer tecnologia. É como criar uma mini-internet dentro da Abril, um sistema distribuído, complexo e adaptativo.
Agradecimentos ao David e Júlio por me explicar essa história e à Abril pelo suporte ao Ruby e novas tecnologias. Ano que vem vamos retornar para ver como foi a evolução do Alexandria alguns meses depois de entrar em produção. Fiquem de olho!