Eu trabalho na Alura e uma coisa bem interessante é que todo nosso sistema é desenvolvido internamente. Isso nos traz muito aprendizado e nos permite customizar todas as coisas para os alunos. E muita gente nos pergunta como funciona nossa arquitetura por trás das milhares de aulas. Esse artigo é um overview de como estamos em 2017.
Aproximadamente um ano atrás, fizemos nossa maior mudança ao lançar um novo site. Além de um redesign completo, também resolvemos dar um grande salto em nossa arquitetura. Muita gente notou que o site ficou com uma performance fenomenal, um design responsivo bem otimizado e até mudanças nos subdomínios. Esse artigo é pra discutir um pouco da Arquitetura do novo site e como chegamos a esses resultados.
A decisão de separar o site da plataforma
Historicamente, todo o portal da Alura era um grande monolito escrito em Java. Isso inclui o site de vendas, páginas de marketing, a plataforma de cursos e até o sistema de pagamentos e relatórios comerciais. É ruim porque temos muita gente mexendo no código, o deploy é demorado e a disponibilidade é uma só (se cair, cai tudo de uma vez).
Na nova reformulação, resolvemos quebrar um pouco. O site externo agora é um projeto separado da plataforma de cursos. Em www.alura.com.br fica o site externo, com foco em apresentar e vender a Alura, em SEO, em marketing. E no cursos.alura.com.br fica a plataforma de cursos, focado em apresentar as aulas, exercícios, fóruns etc.
O Google App Engine
A Alura roda na Amazon desde o início. Temos bastante coisa feita na infra de lá. Usamos EC2 com uma AMI própria e S3 com alguns arquivos estáticos. Os dados ficam no RDS; já o deploy foi automatizado pra rodar lá. Nos serve bem, dada a complexidade do projeto.
Mas é bastante complexo e difícil. Nossos deploys não são tão ágeis. E quando decidimos quebrar o site em um projeto separado, sabíamos que não iríamos precisar de infra complexa. Não só isso: o site precisa de mais agilidade nas mudanças, por ter um foco maior em marketing (por exemplo, subir campanhas promocionais com agilidade).
Há 7 anos usamos o Google App Engine na Caelum; e com muito sucesso! Na minha opinião, é o único PaaS de verdade no mercado. Escalabilidade barata e 100% transparente. Zero trabalho de manutenção de infra e deploy instantâneo, com escalabilidade infinita. Resolvemos ir para o GAE no novo site da Alura.
O PHP
A plataforma de cursos da Alura é em Java. O site da Caelum, que roda no GAE, é em Java. A maioria dos nosso projetos e da nossa experiência por aqui é em Java. Mas decidimos criar o novo site da Alura em PHP.
Nosso maior problema com o site externo, como falei, é que ele precisa ser ágil para mudanças da equipe de marketing e design. Subir campanhas com facilidade, mudar o design do site para comemorar certas datas, testar novas abordagens com foco em marketing e conversões. E o Java não é conhecido por ser simples. Ele tem uma curva de aprendizado e o ambiente de desenvolvimento é mais complexo. Fora que subir o servidor é demorado e fazer um deploy é custoso. O Java é robusto e certamente a melhor decisão pra nossa plataforma de cursos, mas não resolveria o novo site.
Optamos pelo PHP porque o GAE tem suporte e por ele ser simples e acessível a todo mundo da equipe – backenders, frontenders, marketeiros, designers etc. Executar o projeto na máquina do designer é tão simples quanto rodar php -S na pasta do projeto. E é instantâneo.
A arquitetura
Nosso requisito principal era o projeto ser acessível para toda equipe – um clique pra executar e o servidor instantaneamente no ar, – e simples para colocar no ar – um clique pra deployar e a infra toda pronta e escalável. O AppEngine com o PHP caiu como uma luva. Mas temos outros requisitos importantes: o site precisa ser rápido, bom de SEO e integrar com o backend principal da plataforma de cursos da Alura. Algumas coisas aí na nossa stack atrapalharam.
Para manter a simplicidade, decidimos não ter um build-step no projeto. Isso quer dizer que o código que escrevo é o que eu rodo local e é o que eu deployo em produção. Mas isso impediu a gente de usar gulp para otimizações básicas como minificação, concatenação, autoprefixer etc. Então, implementamos várias dessas otimizações de forma transparente no backend com PHP.
Usamos o mrclay/minify para minificar o CSS, JS e HTML. Escrevemos um helper em PHP para adicionar prefixos no CSS automaticamente e implementamos também em PHP um mecanismo simples de concatenar arquivos CSS/JS e de criar sprites SVG.
Além disso, essencial para nós foi o suporte a HTTP/2 do App Engine (e do QUIC). Com isso, a gente tira o foco de otimizações básicas, como simples concatenações, e entram em cena recursos ultra bacanas, como Server Push.
Integração entre sistemas
Um último ponto que vale a pena destacar é que o site da Alura não possui banco de dados, um admin ou back-end complexo. Todo o cadastro de dados, como as informações dos cursos, continua na plataforma de cursos. O site externo consome esses dados através de uma nova API REST que a plataforma expõe. Por exemplo, para saber os valores atuais dos planos de assinatura, chamamos https://cursos.alura.com.br/api/planos.
No lado do site da Alura, fazemos um GET para essas URLs de tempos em tempos, usando Cron jobs e Task queues, do App Engine. Os dados são, então, salvos no Google Cloud Storage e cacheados no Memcache, do GAE, para acesso rápido.
Mais sobre o projeto
Um ano depois da mudança, o resultado é fantástico: foi a melhor decisão que tomamos recentemente. Não só a quebra dos sistemas realmente trouxe a agilidade que queríamos, como a escolha do PHP e a simplicidade da arquitetura realmente facilitaram o dia a dia da equipe. Hoje, até nossos designers que não sabem nada de código já commitam no repositório do projeto.
Com o site da Alura separado do sistema principal, conseguimos focar em uma implementação mais otimizada para os objetivos do site de vendas. O design mais bacana, o front-end que evolui rápido (com flexbox e outras coisas legais), uma performance fenomenal – sério, teste você mesmo -, e um bom SEO.
No começo, como bons javeiros, tivemos algumas ressalvas na equipe quanto a usar PHP. Hoje, essa decisão é vista como das melhores. A simplicidade do projeto é em boa parte por não precisar da stack complicada do Java. E continuamos amando Google App Engine, somos clientes e fãs deles. E a conclusão é que, vira e mexe, em projetos novos, estamos querendo usar a dupla GAE+PHP novamente.
Powered by WPeMatico