O que são aplicações nativas em cloud?

Padrão

Hora de limpar as teias de aranha desse blog. Já faz algum tempo que não posto nada, por vários motivos (nem todos justificáveis hehe).

De qualquer forma, hoje quero abordar um assunto em alta no mercado de TI, as chamadas cloud native applications. Vamos falar um pouco sobre o que elas são, o que comem e onde vivem. Existe uma sopa de letrinhas enorme em torno desse assunto, vamos entender cada uma dessas buzz words. Boa leitura!

Antes de entrar no assunto propriamente dito, vamos dar um passo atrás, fixar alguns conceitos e entender toda a motivação por trás desse novo assunto.

O nome por si só já é bem sugestivo: cloud native applications, ou aplicações nativas em cloud, são aplicações que foram desenvolvidas para usufruir ao máximo dos benefícios intrínsecos da computação em nuvem: consumo sob demanda, facilidade em crescer (e reduzir), auto-serviço, flexibilidade, agilidade, alta disponibilidade etc.

O desenvolvimento de aplicações nativas em cloud é composto por um conjunto de novas abordagens: containers, DevOps e arquitetura de micro serviços.

Não gosto muito de utilizar esse termo, por achar um pouco genérico demais, mas a transformação digital está, de fato, mudando a forma como as empresas lidam com a TI e, principalmente, com seus clientes.

O speed to market é primordial. Ser capaz de desenvolver e entregar aplicações de forma rápida e consistente se tornou peça chave para gerar valor e competitividade para as empresas.

Por exemplo, vide a guerra dos apps: iFood vs Uber Eats vs Rappi. Imaginem o tamanho da demanda por entrega e inovação dessas empresas para se manterem competitivas. Agilidade é crucial!

Para fins de entendimento, vamos fazer um comparativo com as aplicações tradicionais e como elas funcionam atualmente:

O primeiro ponto é a abstração da infraestrutura. Ao contrário de aplicações tradicionais que são altamente acopladas e com uma forte dependência à infraestrutura em que são executadas, aplicações nativas em cloud podem ser executadas em qualquer infraestrutura, consequentemente em qualquer nuvem (pública ou privada).

Com isso, resolvemos um dos maiores problemas no processo de desenvolvimento e entrega de software: dependências, ou em outras palavras:

Chega dessa desculpinha.

É a partir daí que a figura dos containers começa a fazer sentido.

Um container contém todas as dependências que uma aplicação precisa para funcionar: código-fonte, compilador, ferramentas, configurações etc. Embala tudo isso em um único pacote e pronto. A aplicação pode ser executada em qualquer lugar.

Entrando nos aspectos técnicos do funcionamento de um container, pense da seguinte forma: um container é um grupo de processos com uma série de funções de isolamento de kernel aplicadas sobre si, fazendo com que ele ache que está sendo executado em um servidor completo. Enquanto o host sabe que o container é apenas um processo, o container acha que é um servidor completo.

Containers já existem há algum tempo por meio do LXC (cgroups, namespaces e chroot). Agora você se pergunta: então, por que diabos tem se falado tanto disso nos últimos anos? Por que o Docker se tornou tão popular só recentemente?

Bom, por um lado temos a questão da complexidade. Pouquíssimas pessoas sabiam como criar e operar LXC’s, com exceção dos engenheiros-raiz da comunidade Linux. O Docker conseguiu simplificar e tornar essa tecnologia acessível à todos. Acho que também existe uma questão de timing. O Docker surgiu em 2013, em meio ao boom da revolução DevOps.

Acho que ficou claro que a tecnologia de containers é a base do funcionamento das aplicações nativas em cloud, constituindo uma arquitetura baseada em microserviços, que como o próprio nome diz, é uma abordagem utilizada para desenvolver uma unica aplicação como um conjunto de pequenos serviços, cada um executando seu próprio processo e se comunicando através de API’s baseadas em HTTP.

Outro ponto importante em torno de aplicações nativas em cloud é a adoção de cultura e práticas DevOps.

Não vou entrar em detalhes sobre os aspectos de DevOps, pois já falei disso em outro post, fica aqui o incentivo pra você dar uma olhada.

Acho que essa imagem representa bem esse negócio de DevOps

Vamos acrescentar mais letras nessa sopa. Vamos falar de mais um aspecto importante dentro do contexto de aplicações nativas em cloud: CI/CD.

Para dar vazão à agilidade necessária para se criar e atualizar os sistemas, também é preciso repensar a forma como o software é entregue em seu ciclo de desenvolvimento. Alguns chamam isso de pipeline de CI/CD ou simplesmente pipeline.

Um pipeline é um conjunto de processos automatizados que permitem que a equipe de desenvolvimento e a equipe de infraestrutura automatizem o processo de entrega de software em ambiente de produção de forma rápida, ao mesmo tempo, garantindo a estabilidade, qualidade e confiabilidade necessária.

CI/CD é a junção de dois termos: continuous integration (CI) e continuous delivery e/ou continuous deployment (CD) .

  • A integração contínua (continuous integration): é uma prática de desenvolvimento de software em que os desenvolvedores juntam suas alterações de código em um repositório central de forma frequente, permitindo que se façam testes e se identifiquem bugs de forma mais rápida.
  • A entrega contínua (continuous delivery): nesta fase, o código é entregue à uma base específica de usuários para testes específicos de comportamento, e não vai direto para produção. É um passo antes do processo de implantação contínua (continuous deployment).
  • A implantação contínua (continuous deployment): nesta fase do processo, assume-se que todos os testes foram feitos e a única preocupação é automatizar a ida do software para produção.

Todos esses processos integrados e automatizado compõem uma estrutura perfeita para a criação de aplicações nativas em cloud.

Vamos fazer um checkpoint do que falamos até aqui. Falamos sobre a motivação por trás do conceito de aplicações nativas em cloud. Falamos sobre containers, DevOps, CI/CD e arquitetura baseada em microserviços.

Perceba que o conceito de cloud native applications remete à muita coisa nova. Tudo que é novo, no início, tende a ser disruptivo. E tudo que é disruptivo, em geral, leva à uma curva de aprendizado e adoção.

Acredito que é assim com qualquer tipo de tecnologia. Ainda hoje tem gente que enfrenta fila de banco pra pagar conta, não é mesmo? 😉

No fim das contas, existem dois lados nessa moeda: o desenvolvedor e o administrador da infraestrutura. Toda essa conversa em torno de DevOps baseia-se nas seguintes premissas:

  • Permitir que desenvolvedores foquem 100% no desenvolvimento do software, sem se preocupar com aspectos específicos de infraestrutura e, por outro lado;
  • Permitir que a equipe de infraestrutura foque 100% na operação dos sistemas, sem se preocupar com aspectos específicos das aplicações.

Durante esse post tratamos muito do espectro de visão do desenvolvedor. Falamos muito sobre como todas essas tecnologias, práticas e ferramentas, beneficiam o processo de desenvolvimento e entrega de software.

Do ponto de vista de operação e infraestrutura de datacenter, não se trata apenas de instalar e usar todas essas ferramentas. Existem desafios importantes a serem observados, diretamente relacionados à um termo muito utilizado dentro do mundo de cloud: day 2 operations. Alguns desafios comuns ao operar sistemas baseados em containers:

  • Segurança e isolamento das aplicações
  • Redes para containers
  • Persistência de dados
  • Monitoramento e visibilidade
  • Integração entre ferramentas
  • Complexidade de operação

Todas essas novas aplicações precisam ter seu ciclo de vida gerenciado, além de atender aos requisitos de qualquer workload comum: manutenibilidade, disponibilidade, performance, monitoramento etc.

No próximo post, vou falar um pouco sobre o Kubernetes e as soluções de CaaS (container como serviço) para ambientes corporativos disponíveis atualmente no mercado.

Até!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *