A evolução das arquiteturas multicloud

Na Black Friday de 2017 falei sobre a engrenagem que movimenta a megaliquidação mais aclamada do Brasil. Enquanto boa parte das pessoas estava com os olhos voltados para promoções imperdíveis, procurei explicar o que visto por trás das cortinas: por que muitos sites caem durante os períodos de alta demanda ou por que determinado varejo tem resultados melhores que outros, mesmo com descontos menores, durante grandes campanhas como a Black Friday.

A importância da preparação de toda a infraestrutura de TI, é fundamental para oferecer um serviço ao consumidor com constância e qualidade, não importa qual seja o volume de acesso. É possível rodar várias clouds ao mesmo tempo, desde que se saia do desenvolvimento monolítico e adote uma arquitetura de microsserviços, utilizando software containers, que é um empacotamento de software, isolando cada microsserviço, que contêm o seu código, runtimes, frameworks e bibliotecas. Mas, afinal de contas, como eles permitem executar a execução em múltiplas nuvens?

Com a expansão da internet, principalmente da cloud computing, se tornou imprescindível a adoção de uma arquitetura mais moderna de software, a partir da criação de aplicativos baseados em microsserviços. São eles que permitem escalabilidade horizontal e elasticidade, para atender altas demandas e liberar os recursos nas baixas demandas. Aplicativos monolíticos, em oposição aos baseados em microsserviços, enfrentam grandes dificuldades de escalabilidade horizontal. Ao fornecer mais recursos para atender demandas maiores, esse tipo de arquitetura consome muita CPU e memória. Já em uma arquitetura moderna, baseada em microsserviços, a escalabilidade horizontal onera muito menos CPU e memória a cada estanciamento, além de ser muito mais rápida a reação a mudanças de demandas.

Independência em qualquer ambiente

Os containers atuam no isolamento do microsserviço, composto por um pedaço da aplicação e todas as suas dependências, onde cada um desses pedaços está desacoplado (não tem dependências diretas) dos outros pedaços. Quando falamos que linux=container, não estamos brincando: existem quatro principais componentes do Linux que são os responsáveis em manter esse isolamento de software e se o Linux que gerar o container não tiver qualidade, o container também não o terá.

A saber, estamos falando de Linux namespaces que provê os fundamentos do isolamento do container. Um namespace cria uma abstração que faz com que os processos dentro desse namespace achem que têm sua própria instância dos recursos globais. É essa abstração do “Kernel Space” (onde o coração do sistema operacional executa e fornece seus serviços) que se gera a portabilidade do container, ou seja, condições que permitem que ele rode em uma máquina física, virtual, nuvem privada ou pública e habilite o transbordo do datacenter para outros ambientes, seja outro datacenter, nuvens públicas ou qualquer infraestrutura que tenha o Linux compatível instalado.

Outro componente é o SELinux que mantêm os containers isolados um dos outros e do host. SELinux permite que os administradores reforcem o mandatory access controls (MAC) para cada usuário, aplicação, processo, e arquivo. SELinux é a parede que vai impedir alguém de quebrar a abstração do namespace (seja por acidente ou de propósito).

O terceiro componente é o CGroups (ou control groups) que limita e isola o uso de recursos (CPU, memória, disk I/O, rede, etc.) de um conjunto de processos. É o CGroups que assegura que um container terá recursos suficientes e não será parado por outro container no mesmo servidor.

Finalmente, o quarto componente, o perfil de computação segura (Seccomp) que é associado a um container para restringir determinadas chamadas de sistema (system call) e com isso reforçar a segurança e o isolamento do container.

Picos de venda tendem a ser cada vez mais frequentes

A Black Friday e a Cyber Monday não são mais as únicas datas a se preocupar com capacidade de infraestrutura em novembro. O Singles’ Day, feriado comemorado no dia 11 de novembro por solteiros, já é um grande evento do varejo chinês e mundial. Não é por acaso que o Alibaba, a maior empresa de e-commerce do mundo, se prepara tanto para a ocasião. A cada ano a companhia bate recordes de vendas e chega a registrar 256 mil transações por segundo.

Para dar conta de volumes de acesso exorbitantes muita coisa evoluiu, como novas arquiteturas, que permitem abstrair as peculiaridades de cada nuvem, permitindo uma maior mobilidade de uma nuvem para outra, bem como a implementação de arquiteturas multicloud. O principal benefício é não ficar preso a nenhum fornecedor de cloud pública. Entre essas novas tecnologias, estão muito em voga o Service Mesh e o Circuit Breaker.

Monitoramento e prevenção de falha

O Service Mesh é uma plataforma que fornece insights comportamentais e controle operacional sobre a malha de serviços, proporcionando uma maneira uniforme de conectar, proteger e monitorar aplicações de microsserviços. O termo service mesh, ou “malha de serviços”, descreve a rede de microsserviços que compõem as aplicações em uma arquitetura de microsserviços distribuída e as interações entre esses microsserviços. À medida que uma malha de serviços cresce em tamanho e complexidade, ela pode se tornar mais difícil de entender e gerenciar.

A partir do projeto open source Istio, o Red Hat Openshift Service Mesh acrescenta uma camada transparente sobre aplicações distribuídas sem exigir qualquer mudança no código do serviço. Por meio dele é possível criar facilmente uma rede de serviços implantados que fornecem descoberta, equilíbrio de carga, autenticação serviço a serviço, recuperação de falha, métricas e monitoramento. Uma malha de serviços também traz funcionalidades operacionais mais complexas, incluindo teste A/B, canary deployment, limitação de taxa, controle de acesso e autenticação ponta-a-ponta.

Já o Circuit Breaker é um padrão de design aplicado no desenvolvimento de software moderno. É usado para detectar falhas e encapsular a lógica de prevenir falhas originadas da recorrência constante de acesso, durante a manutenção, falha externa temporária ou dificuldades inesperadas pelo sistema. É como funciona o fusível na sua casa: no caso de um curto circuito, para evitar um incêndio, o fusível se desarma isolando uma área. Este recurso geralmente é usado para checar a disponibilidade de um serviço externo, uma vez que previne que a aplicação tente executar uma ação condenada ao fracasso até que seja seguro tentar novamente, evitando o “incêndio” na sua aplicação.

Seja na Black Friday, Singles' Day ou qualquer outra data em que se espera um salto brusco no número de transações, os containers proporcionam a solução mais segura e eficaz para lidar com os microsserviços. É a partir desse conceito que conseguimos endereçar as questões de infraestrutura diante de uma demanda intensa e gerenciar transbordos entre ambientes de forma confiável e eficiente, não importando o tamanho da malha de serviços e seu grau de complexidade.