TUDO SOBRE EAD

Coloque o seu email aqui para receber gratuitamente as atualizações do blog!

Stack Edools – conheça as tecnologias que usamos


stack

Aqui no Edools nós somos apaixonados por tecnologia. Além de sermos geeks por natureza, temos plena consciência do impacto positivo que as tecnologias de ponta têm no nosso cotidiano. Automatizando e otimizando tarefas, nos poupam tempo para focar no que realmente importa. Isso se reflete no desenvolvimento do Edools.

Para construir uma plataforma robusta e segura de maneira ágil e eficiente, selecionamos cuidadosamente cada ferramenta e framework que atendesse nossas necessidades. Particularmente, sempre fui curioso em conhecer como os grandes produtos que usamos, como Google e Facebook, organizam sua infraestrutura e o que eles usam em suas stacks de desenvolvimento. Agora, chegou minha vez de compartilhar com vocês as principais engrenagens que usamos no nosso produto!

Coloque o seu email aqui para receber gratuitamente as atualizações do blog!

Infraestrutura

Quando o assunto é infraesturua na nuvem, a Amazon reina na web. Desde 2006 fornecendo serviços de hospedagem na nuvem, como o Amazon EC2, o Amazon Web Services nos entrega  segurança e escalabilidade. Com ele temos desde opções PaaS, como o Elastic Beanstalk, que funciona de maneira similar ao Heroku, e também IaaS. Desta última, um excelente exemplo é o CloudFormation, em que descreve-se todos os recursos do AWS que deseja utilizar em um arquivo JSON, e ele levanta automaticamente todos os recursos para sua aplicação. Ou seja, atende diferentes necessidades.

Um dos recursos mais bacanas é o Auto Scaling, sendo um dos grandes diferenciais da Amazon nesse mercado. Graças a esse recurso, nós conseguimos definir diferentes gatilhos para fazer os servidores escalarem de forma automática. Se houve um pico no tráfego entrando nos servidores de nossa aplicação, o Auto Scaling adiciona mais instâncias para suportar a demanda. Se está ocorrendo pico no consumo de CPU, adiciona mais instâncias. Se cair um meteoro nos servidores na zona da Virginia, ele sobe mais instâncias em Oregon para não deixar a aplicação fora do ar. Esse cara é um dos grandes responsáveis por dormirmos em paz.

Monitoração

Levamos muito a sério a estabilidade do nosso produto. Nós buscamos usar ferramentas que nos possibilitem saber de tudo o que se passa na nossa aplicação, para detectarmos os bugs muito antes deles serem percebidos pelos clientes, e então agirmos para solucioná-lo. Atualmente, as principais são o NewRelic, Pingdom, Papertrail, RollbarLoader.io.

O NewRelic é fantástico. As últimas atualizações na UI deixaram a interface muito mais agradável do que já era, sem perder na qualidade das informações. Métricas importantes  respeito da performance da aplicação são obtidas em tempo real, com alto nível de informação. É possível identificar quais os endpoints da sua aplicação estão sendo o gargalo, mais especificamente em quais chamadas de funcões. É lindo. Outra métrica interessante é o Apdex, que mede a qualidade com a qual sua aplicação está servindo as requisições, dado um threshold definido. Também usamos o Pingdom, que é mais conhecido, para auxiliar na detecção de downtimes.

Para monitorar o log e a ocorrência de exceções em produção, entra a dupla Rollbar e Papertrail. O primeiro é integrado diretamente no nível da aplicação, e sempre que uma exceção (a.k.a bug) acontece, ele salva um report completo com informações relevantes para auxiliar nossos desenvolvedores a debuggar. Já o Papertrail, ele pode ser integrado no nível da aplicação, mas o mas recomendado é que seja direto nos servidores. Dessa forma, ele irá agrupar o log de todos os serviços. Com uma busca de qualidade, é muito útil também debuggar em produção.

Loader.io é uma descoberta recente, mas que caiu como uma luva no nosso fluxo de desenvolvimento. Ele funciona mais como prevenção. Basicamente, define-se uma url para se fazer teste de carga. As configurações são simples, onde é necessário selecionar a quantidade de clientes que se deseja testar ao longo de um determinado período. Além disso, também é preciso definir um limite para a quantidade de requests falhas (400/500 e timeouts). Aperte o play, e ele irá recrutar os hamsters para realizar o teste. Sendo assim, você consegue cobrir diversos pontos da sua aplicação com testes de performance de maneira simples e rápida. Rodando periodicamente tais testes, ou incluindo ele na pipeline de deploy, você consegue uma boa medida para prevenir códigos com baixa performance entrando em produção.

BackEnd

Ruby on Rails reina aqui no Edools. Além de ter uma enorme comunidade vibrante e apaixonada, suas práticas e convenções são amplamente adotadas por todos. A simplicidade e agilidade proporcionada são os seus pontos fortes. Em poucos minutos você consegue criar uma nova aplicação, fazer deploy em um PaaS, como o Heroku, e disponibilizá-la aos seus usuários. Isso contribui muito para aqueles que adotam metodologias ágeis, visando ciclos rápidos de feedback. Ainda por cima, é um framework extremamente robusto, já na sua quarta grande versão, utilizado por grandes empresas como Twitter, Github e Shopify.

Outro framework que adotamos recentemente em alguns projetos é o NodeJS. Construído em cima da runtime Javascript do Chrome, usa um modelo orientado a eventos, onde não há bloqueio de I/O. Se encaixa bem em projetos com um intenso fluxo de dados, em tempo real, como por exempo um chat. Mas vem evoluindo bastante ao longo dos anos, surgindo algumas soluções que querem fornecer aos desenvolvedores os mesmos benefícios do mundo Rails, como o Sailsjs. Ebay, Pearson e PayPal, são alguns exemplos de grandes que o adotaram.

Aqui nós gostamos de agilidade, porém temos consciência de que para construir um grande produto ele precisa ser feito com qualidade, sendo que uma característica não pode anular a outra. Para nos auxiliar na manutenção de um código com qualidade, usamos o CodeClimate. Ele é uma mão na roda. A cada commit ele monitora métricas como qualidade, segurança, estilo e cobertura de testes. Com essas informações, o desenvolvedor ganha mais confiança na hora de fazer merges e revisar pull requests. O Fábio Akita escreveu um excelente post sobre o assunto que vale dar um conferida.

Banco de Dados

O armazenamento de dados é algo intrínseco no desenvolvimento de qualquer aplicação hoje em dia. Hoje existe uma grande cartilha de opções para selecionar, onde o que define qual usar vem da natureza do problema que se deseja solucionar. Os relacionais continuam sendo os mais utilizados, já que atendem muito bem o as aplicações web de pequeno a grande portes (Google, Facebook e Twitter são gigantes, né?). Nos nossos principais projetos nós utilizamos como principal banco de dados relacional o PostgreSQL. Seu desenvolvimento ao longo dos anos foi muito bom e ganhou o lugar do MySQL no nosso coração. Sua confiança e estabilidade são classificadas como lendárias, dado muitos testemunhos de anos de uso sem ter quebrado nem uma única vez sequer.

Como mencionei, nem sempre um banco relacional é a melhor solução. Em alguns casos, quando precisamos de uma esquema mais flexível por exemplo, usamos o MongoDB, que usa um modelo orientado a documentos. Além dele, usamos também o Redis, um banco de chave-valor bem avançado. Ele é amplamente usado para cache, e muitas soluções para controle de gerenciadores de tarefas em brackground são construídas com base nele.

FrontEnd

No front-end, além dos já conhecidos HTML5 e CSS3, nós utilizamos Bower, Gulp e AngularJS. Os dois primeiros vieram ao mundo para acabar com o pesadelo que era a manutenção de projetos web há um tempo atrás. O Bower é um gerenciador de pacotes para a web, como ele se auto denomina. Funciona como um Gemfile  ou um package.json. Você define quais bibliotecas quer, suas versões, e ponto. O Bower cuida de caçar e baixar para você. Já o Gulp entra no jogo para automatizar tarefas comuns no desenvolvimento.

O AngularJS é a nossa escolha para framework frontend. Foi desenvolvido pelo Google, com o mantra de estender o HTML para torná-lo mais naturalmente dinâmico. Além de ser o mais popular, ele foi densenvolvido para suportar testes naturalmente. As suas diretivas ajudam o código ficar mais limpo, e seu casamento com o HTML elimina a necessidade de uma engine de template, como outros frameworks. Recentemente, a BBC fez um post explicando como refizeram a página inicial deles usando AngularJS.

Teste gratuitamente o Edools por 15 dias.

E mais…

Bom, demos uma passada geral pela stack atual do Edools. Em conjunto com o que citei, usamos diversas outras ferramentas para unir tudo isso. Com o Rails usamos Nginx + Unicorn, uma combinação que vale vários outros posts. No AWS usamos diversas ferramentas, como EC2, RDS, OpsWorks. Estamos começando a usar o Docker em algumas partes. Tem também o Codeship na nossa pipeline de Continuos Integration. E para comunicação, centralizando todas essas notificações de tantos serviços, entra o Slack. Porém, estamos em constante evolução. Sempre em busca das melhores soluções para fornecer aos nossos clientes plataformas seguras, estáveis e de alta performance.

Se você curte saber o que está por baixo dos produtos de grandes empresas, dá uma olhada no StackShare. Esses caras organizaram as stacks de grandes empresas em um único lugar. Você pode conferir tudo o que estamos usando atualmente aqui.

É isso aí, fique ligado!

Como abraçamos o ES6 em nossas aplicações - Parte 2 - Controllers

Conteúdo VIP

Coloque o seu email abaixo para receber gratuitamente as atualizações do blog!

Sobre Vinicius Magalhães

Vinicius - CTO do Edools - é um empreendedor engajado amante de tecnologia e inovação que busca impactar a vida das pessoas construindo soluções inovadoras e inteligentes. Adora um bom e velho café e é fã do C.R. Flamengo. Também é cientista da computação formado com honra pela UFRJ e possui sólidos conhecimentos em processos empresariais adquirido em sua passagem pela consultoria Visagio. Antes de se tornar CTO do Edools participou da construção da rede social de descontos DicaX como principal membro do time de tecnologia.
Ver todos os posts de Vinicius Magalhães

Comentários (6)


  1. 12/03/2015 às 11:41

    Bom stack.
    Eu utilizava o Pingdom também até começar a monitorar o downtime também pelo NewRelic, ele também tem essa feature.

    abs

    • Vinicius Magalhães
      16/03/2015 às 09:25

      É verdade, Luciano. Nós de fato também estamos usando essa feature do NewRelic internamente, em conjunto com o Pingdom. Ainda não saímos dele pela página de status que ele nos fornece.

      Grande abraço

  2. 11/06/2015 às 16:25

    Legal por compartilhar, Vinicius! Fantástico o Stackshare. Pra nós, curiosos, é um prato cheio!
    Bem interessante as ferramentas que vocês estão utilizando. Gostei de conhecer o Loader.io
    Para monitoramento da camada de Infra, vi que o Datadog é uma opção que tem crescido bastante. Vocês chegaram a compará-lo com o New Relic ou vocês usam o New Relic pra infra + app?
    Quanto aos logs, chegaram a comparar o Papeltrail vs Loggly?

    • Vinicius Magalhães
      12/06/2015 às 08:31

      Oi Sergio! O Datadog tem crescido bastante mesmo. Na verdade nós começamos a estudá-lo há umas semanas atrás, e ainda vamos fazer alguns testes. Sobre o Papertrail vs Loggly, na época chegamos a testar sim e o time preferiu o Papertrail pela simplicidade e usabilidade. Mas pelo que vi agora, o Loggly mudou bastante, vou até dar uma olhada mais a fundo. Valeu!

      • 17/06/2015 às 01:17

        Bacana, Vinicius. Conheci o Datadog em uma palestra na QCon Rio 2014 de 2 brazucas que fazem parte do time de DevOps da ZenDesk. Lá eles usam tanto o Datadog quanto o NewRelic, porém ambos com papéis diferentes no que se refere a monitoramento da Infra. O link caso queira assistir é este http://www.infoq.com/br/presentations/devops-na-zendesk . Eles falam de vários outros SaaS que usam para operar a Infra da ZenDesk, além de processos e cultura adotados na empresa. Agora que a Edools está decolando, pode ser legal este conhecimento. Recomendo assistir com bastante calma, pois o conteúdo é denso! Abraço.

        • Vinicius Magalhães
          17/06/2015 às 09:15

          Show, Sergio. Muito obrigado pela contribuição! Abs.

Deixe uma resposta