Todos nós empreendedores e desenvolvedores de software queremos que as aplicações que desenvolvemos façam grande sucesso! Mas quando alcançamos esse sucesso, surgem alguns novos desafios que precisamos enfrentar, é o que Ruslan Meshenberg da Netflix chama de as dores de cabeça do sucesso.

Quando sua aplicação realmente faz sucesso, você, muita vezes, precisa de mais desenvolvedores, tem mais clientes e requests para atender, precisa aumentar a disponibilidade, distribuir a aplicação globalmente com tempo de resposta recorde e baixa latência.

Para resolver esses problemas de sucesso, a Netflix utiliza a AWS como plataforma de Cloud Computing. A empresa migrou de uma aplicação monolítica, que era um gigante projeto Java/Web que faziam deploy através de um único pacote WAR, para uma arquitetura com centenas de microservices.

Uma aplicação monolítica geralmente tem uma arquitetura semelhante a essa:

Mas para que consiga sobreviver ao “Sucesso” precisa ser mais parecida com essa:

A boa notícia, é que a Netflix já resolveu esse problema, por ter um desafio tão grande quanto ter que segurar 30% de toda a demanda da Internet da América do Norte, e não apenas resolveram isso tudo, como disponibilizam a maior parte do stack de ferramentas que utilizam como software open source para que você também possa utilizar em seus próprios projetos para criar uma arquitetura de microservices reativa.

Veja algumas empresas além da Netflix que utilizam os projetos Open Source da Netflix (Netflix OSS):

Já são mais de 50 projetos open source que a Netflix publicou no Github deles. Aproveite!

De acordo com Meshenberg, as principais características para uma aplicação altamente disponível são:

Decomposição em Microservices: Permitir que o o acesso para usuário final esteja sempre disponível, de forma que se uma parte da aplicação falhar, o restante permaneça em funcionamento, não permitindo que a falha se espalhe no sistema como um todo. Há times que cuidam de todo o ciclo da aplicação, desde o desenvolvimento, ao deploy, e até a operação.

Redundância e Latência: Todos os seus serviços devem estar rodando em diversos data centers, e em diversas regiões do mundo. Para isso a Netflix faz deploy dos recursos de Infraestrutura nas diversas AZs e Regiões da AWS.

Para conseguir isso, você pode utilizar alguns componentes do Netflix OSS, veja:

Eureka: O projeto Eureka, atua como um service registry, ele conhece todos os serviços e sabe o status de cada um (iniciando, em execução, fora do ar, etc.) e em que máquina, zona, região e IP que estão sendo executados.

Karyon: O projeto funciona como uma dependência (java/jar) de cada um dos microservices e se encarrega dentre outras coisas de realizar o registro do microservice no Eureka, para que o microservice possa ser rapidamente e facilmente encontrado pelos outros serviços que precisarem dele.

Ribbon Client: esse éo projeto open source responsável pelo client de IPC (Interprocess Communication), em outras palavras ele é responsável por realizar a comunicação entre os diversos microservices e fazer o balanceamento de carga (client side), suportando diversos protocolos (HTTP, TCP, UDP) inclusive para chamadas assíncronas e arquiteturas reativas. O Ribbon também faz o tratamento de uma eventual falha em uma chamada de um microservice. O Ribbon oferece diferentes implementações de LoadBalancer para que você utilizar.

Veja o Ribbon, Karyon e o Eureka trabalhando juntos numa arquitetura reativa:

Hystrix: é outro projeto open source da Netflix, o trabalho dele é aplicar o famoso padrão de arquitetura circuit breaker. Quando um determinado microservice falhar, ele “abrirá o circuito” e direcionará as chamadas para um outro microservice que atuará como um fallback. Para mais informações leia o artigo Desenvolvendo aplicações resilientes e escaláveis: O front door da Netflix.

Veja na imagem para compreender melhor como esses componentes colaboram:

Uma arquitetura de microservices deve assumir que tudo que pode falhar cedo ou tarde vai falhar, por isso deve se prevenir para que a aplicação continue disponível mesmo em caso de falhas em alguns dos componentes da arquitetura, por isso Meshenberg fez questão de enfatizar em sua apresentação que o estado da aplicação (dados) deve estar apenas na camada de persistência (seja isso um banco de dados ou cache store como Memcached ou Redis), isso significa que você não poderá contar com estado em sessões de usuário (HTTP Session Store) nos servidores web.

Isso é importante porque se um desses servidores cairem, sua aplicação deverá continuar funcionando normalmente sem que o usuário note o que aconteceu. Sem contar que para um balanceamento de carga eficiente você nem sempre poderá contar que todas as requests de um usuário serão atendidas pelo mesmo servidor (no sticky session). Além de tudo, isso será um pré-requisito para que você faça atualizações da sua aplicação sem causar downtime (indisponibilidade).

Outro ponto importante para garantir a alta disponibilidade são os testes de falhas de recursos de infraestrutura. A Netflix faz testes de como a aplicação reage caso um microservice pare de responder, caso um servidor pare de responder, caso um data center inteiro pare responder e até caso uma região inteira da AWS pare de responder. Para isso utilizam o projeto  SimianArmy que oferece um conjunto de ferramentas para testar a segurança e os mecanismos de fail-over da sua aplicação. O Chaos Monkey por exemplo derruba instâncias EC2 aleatoriamente.

Ainda falando de alta disponibilidade, para garantir o deploy de aplicações sem downtime, a Netflix desenvolveu o Asgard que é um projeto open-source para gerenciar deploys (atualizações de versão). Com ele é possível realizar Canary e Red/Black Deploys, técnicas de deploy que permitem realizar atualizações de software sem causar downtime algum, ou seja, sem tirar a aplicação do ar, e ainda é possível fazer rollback para a versão anterior caso ocorra algum problema no meio do processo de deploy.

Outros projetos úteis do Netflix OSS

O projeto Archaius pode gerenciar as configurações dos diversos microservices. Com ele você criar propriedades dinâmicas que podem ser alteradas em tempo de execução. Para utilizá-las em sua aplicação Java basta faz uso de Annotations.

O projetos Servo e Atlas, oferecem recursos para que você monitore suas aplicações.

O projeto Aminator te ajuda a criar AMIs (imagens de máquinas virtuais) para serem distribuídas na AWS.

Implementação de Referência

Eu sei, eu sei… São tantas coisas que você pode estar se sentindo um pouco perdido. A boa notícia é que para facilitar a nossa vida, Chris Fregly, criou uma implementação prática de todos esses projetos trabalhando juntos, o Flux Capacitor e o código fonte está no Github, veja nesse curto vídeo como funciona.

Para aprender mais

Veja as apresentações de Ruslan Meshenberg e de Sudhir Tonse  no evento AWS Re:invent 2014 para aprender mais:

Conclusão

Aplicações de alta disponibilidade requerem um arquitetura distribuída e resiliente (a prova de falhas). A Netflix é pioneira nesse tipo de arquitetura e disponibiliza uma grande gama de projetos open source que podem ajudar você a construir uma aplicação assim.

Esse caminho não é fácil, e há muito o que ser aprendido, eu estou me empenhando bastante para trilhá-lo, e pretendo compartilhar tudo o que venho aprendendo com você aqui no Blog.

Recomendo também a leitura do livro da Susan Fowler sobre Microservices para você aprender mais sobre o assunto.

Deixe seu comentário e assine o blog por e-mail, feed ou em uma das redes sociais para não perder nenhuma novidade.