A arquitetura do novo site da Alura

Dia 1º de Março a gente lançou o novo site da Alura. Além do fantástico novo visual, muita gente reparou nos diversos outros detalhes: subdomínio separado da plataforma de aulas, a performance fenomenal do site novo, o design responsivo etc. Neste post quero discutir um pouco da Arquitetura do novo site e como chegamos nesses resultados.

A decisão de separar o site da plataforma

Historicamente, a Alura todo era um grande monolito escrito em Java. Isso inclui o site de vendas, páginas de marketing, a plataforma de cursos, o sistema de pagamentos e até códigos  do MusicDot. É ruim porque temos muita gente mexendo no código, porque o deploy é demorado, 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.

Screenshot 2016-03-02 15.09.19

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. S3 com alguns arquivos estáticos. Os dados ficam no RDS. 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 (ex. subir campanhas promocionais com agilidade).

Há 7 anos que 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. Deploy instantâneo com escalabilidade infinita. Resolvemos ir para o GAE no novo site da Alura.

Screenshot 2016-03-02 15.11.59

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. Tem uma curva de aprendizado. O ambiente de desenvolvimento é mais complexo. Subir o servidor é demorado. 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 – 1 clique pra executar, servidor instantaneamente no ar, – e simples para colocar no ar – 1 clique pra deployar, 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 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 tira-se o foco de otimizações básicas como simples concatenações. E entram em cena recursos ultra bacanas como Server Push. Isso tudo merece um post a parte para mostrar o impacto de se usar HTTP/2.

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

O projeto do novo site da Alura começou a sair do papel no final de 2015 com a criação e design. Muitas pessoas participaram da implementação. Na equipe de front-end estavam Fernando Stefanini, Jana Paradiso e Yuri Padilha. No back-end e APIs, Philippe Ehlert, Rodrigo Turini, Felipe Oliveira e Caio Incau. Além de Caio Souza na reorganização do conteúdo e dos designers Thiago VilaçaFabio Gushiken.

Muitas outras coisas bacanas aconteceram no projeto. Fizemos uma implementação responsiva mobile-first, usando flexbox no CSS, sistema de ícones em SVG. Fizemos várias otimizações para ficar com excelente performance. Nos próximos dias vamos contar mais detalhes sobre o site.

E você, o que achou do site? E das nossas decisões arquiteturais?


  • Marcos

    Parabéns. Ficou fantástico..
    Eu fui umas das pessoas que participaram do teste de usabilidade.
    Seria bacana um curso no alura de PHP no GAE.
    Se implementasse sistemas de pagamento (pagseguro e paypal), SEO e SEM eu compraria na hora! ;).

    Parabéns pelo trabalho.

  • João José Maranhão Junior

    Sou aluno Alura e adorei o novo site, ótimo trabalho!!

    Uma pergunta :Qual seria uma outra opção além do Php sem retirar essas vantagem?

    • Sérgio Lopes

      A gente cogitou o Python também lá no GAE e o Node.js nas Managed VMs do Google. Mas no fim ainda acho que a simplicidade do PHP é maior. A grande vantagem pro nosso cenário foi poder escrever as páginas direto em PHP sem exigir frameworks e instalações complicadas.

  • Meriellen Silveira

    Sérgio o novo site está ótimo!

    Gostaria de saber mais sobre o front-end se vocês usaram alguma arquitetura ou framework e a organização dos arquivos.

    • Sérgio Lopes

      Segunda feira sai mais um post, mais focado no front (sobre a Performance do site novo!).

      Mas respondendo sua pergunta: não precisamos de nenhum framework (nem CSS nem JS). Fizemos o CSS todo modularizado em componentes (uns 40 diferentes). Tudo Mobile-first com Flexbox como base (e fallbacks pra browsers antigos).

      Estou gravando um curso no Alura agora inspirado no novo site. Vai ser o Projeto do site do começo ao fim e vou mostrar em detalhes o front, o CSS, o responsivo etc. Deve sair mês que vem 🙂

      • Meriellen Silveira

        Ótimo Sérgio, vai ser muito bom ver como um site profissional e com bom desemprenho é feito. Ficarei no aguardo do curso!

      • Erick Munekata

        Muito bacana Sérgio!

        Estarei aguardando ansiosamente pelo curso para poder ver como foi implementado!

  • Edwi Feitoza

    Parabéns a todos os envolvidos! O trabalho ficou sensacional!

    Se me permite uma dúvida, li um trecho da publicação que pode gerar uma certa polêmica. Segue:

    “Na minha opinião, é o único PaaS de verdade no mercado.”

    Quais features que você vê no GAE que te faz falta em outras plataformas PaaS do mercado (como o Beanstalk, por exemplo)?

    Obrigado!

    • Sérgio Lopes

      É, fui polêmico. Obrigado por morder a isca e me permitir expandir o assunto hahaha.

      No GAE a gente tem escalabilidade instantânea e transparente. Isso quer dizer que ele responde automaticamente a picos e dispara novas instâncias que estão no ar em questão de poucos segundos. É bem diferente do AWS que preciso ficar louco com configs de autoscaling dele. E bem diferente de instâncias novas do EC2 que demoram minutos pra bootar. O beanstalk, no meu entendimento, é só um facilitador pros servicos do AWS e ainda tem as mesmas limitações.

      No GAE ele sobe e mata instâncias da aplicação a todo instante. Não preciso me preocupar com nada de infra, como updates do servidor. Cada instância nova já sobe em segundos) com máquina atualizada. E ainda tem uma série de serviços prontos no SDK que é só usar sem burocracia.

      Mas o GAE não é pra todos. Ele coloca limitacoes importantes na aplicação pra poder dar essas features.

      • Ótimo blog post Sérgio. Se me permite tenho algumas várias perguntas 🙂

        Chegou a dar uma olhada no heroku? É bem fácil fazer deploy pra lá e até onde eu usei escala fácil também.

        Fiquei curioso se o PHP foi escolhido pela simplicidade, por que não fazer o site totalmente estático? Tem alguma razão por não ter escolhido esse caminho? O setup da Amazon ficaria muito mais simples.

        E por que não fazer o build do projeto com gulp ou qualquer coisa assim? Qual problema isso resolve?

        E por último o site cursos.alura.com.br ainda está em Java? Pelo que eu vi ainda está na AWS. Qual o motivo para não migrá-lo para o GAE também? Imagino porque a infra-estrutura seja mais complexa, certo?

        Obrigado pelo blog post e espero não ter perguntado demais 🙂

        • Sérgio Lopes

          O heroku é certamente uma opção. Bem melhor que um beanstalk. Usamos aqui em alguns projetos mas ainda acho que o gae esconde mais as dificuldades de infra.

          Cogitamos geradores de sites estáticos mas eles atrapalharam um pouco em dev. Usamos jekyll no site do vraptor e eu uso docpad no meu Blog pessoal. E apanhamos já em ambos os cenários. O php pareceu mais simples.

          Mas implementamos o php de forma que em produção o site é praticamente estático. Ele gera o HTML 1x e cacheia. Todos os requests subsequentes são servidos instantaneamente. Um dos motivos pro site estar rápido.

          Do gulp, essa é uma decisão ainda em aberto. A motivação pra não usa-lo era ter One click deploy em 5s. Sem build. Só o php é necessário pra desenvolver e deployar. Mas talvez tenhamos ido longe demais. Implementar em php as otimizações deu um certo trabalho.

          Por fim, sim a plataforma de cursos é em Java no AWS. O que nos atende muito bem pra esse projeto.

          • Muito obrigado pelas respostas, Sérgio.

            Interessante essa configuração de vocês, eu gosto mais da abordagem do site estático usando S3 + CloudFront assim não me preocupo com nenhuma infra ou nenhum problema de escalonamento,

            Mas é sempre bom poder aprender o que os outros estão fazendo. Boa sorte pra vocês.

          • E pensando em SEO também, seria um pouco penoso um site estático consultando as APIs via javascript. Segundo o Google, eles já executam javascript no crawler, mas eu prefiro ter tudo escrito no HTML de qualquer forma. A solução com Cron Jobs e Task Queues resolve isso muito bem. 🙂

            Ótimo post, como sempre.

  • Anônimo

    O novo site ficou realmente muito bom.

    Uma dúvida: Por que não é mais possível encontrar o curso de Entity Framework?

  • Jean Cesar

    Parabéns pelo post e adorei o novo site do alura. Mas fiquei na dúvida, no lugar do php não daria para usar o ruby?

    • Sérgio Lopes

      Daria sim. Optamos pelo php pela simplicidade. Usa o servidor builtin dele pra testar, já tem uma lib padrão completa pra web.

      O ruby a gente ia precisar de frameworks, gems, servidores. Nada contra, mas o setup com php é ainda mais simples.

  • Nossa, excelente, gosto muito de ler esses cases de implementações porque economiza tempo para todos. Parabéns ao Alura e todos da equipe.

  • Muito show, fico sem palavras, site muito rápido, … Acredito que a consequência disso é redução de custos $$.

    Mas, tenho uma dúvida maluca sobre a integração entre os sistemas: Mesmo usando o Memcache, o Google Cloud Storage é uma maneira de lidar com algum “reset inesperado” do Memcache?

    • Sérgio Lopes

      Exato! O memcache é volátil então salvo no cloud storage como backup.

  • Parabéns pelo artigo e pelo novo site do Alura, ficou muito bom. Gostaria de perguntar se, junto com a consideração de utilizar o PHP, consideraram utilizar WordPress?

  • Wilker

    Meus parabéns para toda a equipe, uso muito o alura e experiência que estou tendo com esse novo design poderia ser melhor. Estou curtindo bastante.
    A plataforma de cursos ficou bem mais descontraída e amigável.

    Mais uma vez meus parabéns

  • Pingback: Blog do Alura – Pequenos ajustes, grandes mudanças!()

  • Excelente. Ficou ótimo! Você estão de parabéns! PHP Rocks!

    Sobre o PHP, vocês estão utilizando algum Framework?

  • Mahmod Issa

    Espetacular!!!!

  • david

    Quais chances de compartilhar o código fonte no git ? 😛

  • Andre Kauling Justi

    Opa, primeiramente parabéns pelo post e pela arquitetura, muito bacana, fiquei em duvida sobre uma coisa, o sistema de vendas (ecommerce) é o mesmo do sistema dos cursos? se sim porque dessa decisão visto, que são coisas diferentes, e se não como foi e quais foram as dificuldades de integração

    • Bom dia Andre, a decisão de separá-los foi de que é muito mais fácil fazer atualizações no site de vendas sem precisar fazer um deploy do sistema completo. Isso facilitou para que, por exemplo, o designer possa fazer qualquer alteração a qualquer instante sem impactar no sistema das aulas

  • Pingback: Performance Web no mundo real: porque o site da Alura voa | blog.caelum.com.br()

Próximo ArtigoJSON e Objeto JavaScript são a mesma coisa?