Ao longo dos últimos anos Cloud Native tem estado em evidência.

Há a oportunidade de retrocesso? É hype?

Sempre teremos quem defenda que tudo é hype! Por quê com Cloud Native seria diferente? Na real, essas pessoas em geral adiam por anos o estudo por julgaram que algo é hype, até não conseguirem mais se movimentar no mercado sem um determinado conhecimento.

Esse é o momento em que muitos optam por fazer uma transição de carreira.

Se você não pretende seguir em outra carreira, e sim trabalha com Backend, principalmente .NET, esse post visa mostrar um pouco do universo Cloud Native e mostrar como chegamos até aqui.

Cloud Native no Microsoft Build 2022

O termo “Cloud Native” esteve presente durante toda a edição do Microsoft build 2022. Do Keynote do Satya até as demos e mais demos.

Definindo: O que é Cloud Native?

Tecnologias nativas ao cloud empoderam empresas a criarem e rodarem aplicações escaláveis em ambientes modernos e dinâmicos, como nuvens públicas, privadas e híbridas. Containeres, service meshes, microsserviços, infraestruturas imutáveis e APIs declarativas são alguns exemplos dessa estratégia.

Essas técnicas permitem criar sistemas de baixo acoplamento, resilientes, gerenciáveis e observáveis. Combinadas com automações robustas, elas permitem que os engenheiros façam alterações de alto impacto de forma frequente e previsível, com o mínimo de esforço.

A Cloud Native Computing Foundation procura conduzir a adoção desse paradigma auxiliando e sustentando um ecossistema de projetos de código aberto e não atrelados a nenhum fornecedor. Nós democratizamos padrões estado-da-arte para fazer com que essas inovações sejam acessíveis a todos.

https://www.cncf.io/about/who-we-are/

Essa é a definição proposta pela CNCF.

Lendo essa definição conseguimos entender superficialmente do que se trata, mas ainda parece abstrato. Então para entender Cloud Native precisamos entender de onde viemos e para onde estamos indo.

Mas antes, precisamos conhecer a CNCF e sua origem.

Shayne Boyer pode te ajudar a desmistificar o que é Cloud Native:

“API’s, Serverless e Containers, todos gerenciados em uma infraestrutura imutável.”

Brandan Burns, Ex-Líder de engenharia do Kubernetes, na google de 2008 a 2016 diz:

Acho que em muitos aspectos essas palavras que estamos usando, eles são apenas uma abreviação que podemos usar para discutir ideias e conceitos que entendemos juntos.
Eu acho que sua definição talvez um pouco diferente da minha definição, mas no caso geral, vai ser a mesma coisa.
Para mim, há duas características realmente importantes para o Cloud native.

Uma é que há uma expectativa de infraestrutura orientada por API.
Então eu vou ser capaz de criar uma máquina com uma chamada de API.
Eu posso criar um banco de dados e, em seguida, chamar a API.
Eu posso fazer basicamente o que eu preciso fazer de forma programática, em vez de criar um ticket em um sistema e alguém pegar uma máquina física e colocar em um rack.

É muito mais como se eu só quisesse dizer o que é realmente necessário para criar algo, via API.

Acho que a outra parte é uma noção de elasticidade e como fungibilidade, ou seja, se eu precisasse de uma nova VM, eu não me preocupo há partes em algum lugar, como é a cadeia Intel ou AMD? Eu diria e você não conhecia a máquina e eu obter uma nova máquina e vice-versa. Se eu precisar descartar alguma coisa, eu simplesmente descarto.

Então eu estava conversando com alguém um tempo atrás sobre essa ideia de devolver espaço.

Se você vai lançar uma nova infraestrutura, você tem que pensar em quanto espaço físico há nesses datacenters e o mar de novas máquinas ao lado das máquinas antigas para agora ou para a próxima hora, quando eu estiver dropando um serviço antigo e criando o novo.

Em um mundo cloud native, você não precisa pensar nisso.

Você apenas pensa: Eu vou criar um novo conjunto de VMs! Não sei onde, eles estão lá na Nuvem. Eu não vou ter que pensar sobre isso. Eu vou ser capaz de fazer essas coisas elásticas.

Eu acho que isso leva a esses padrões como Blue-Green Deployments.

Eu não acho que você poderia dizer que Blue-Green Deployment poderia existir em um mundo sem cloud, porque para poder suportar isso, eu tenho duas cópias do meu aplicativo rodando ao mesmo tempo. No datacenter, eu precisaria de dois conjuntos físicos de servidores para rodar dessa forma.

Mas em um mundo de cloud, eu apenas crio um novo conjunto de VMs, elas se sobrepõem por uma hora e em seguida jogamos fora.

Blue-Green Deployments é um ótimo exemplo de cloud, como um dos primeiros padrões cloud native que aconteceram por aí.

Então eu acho que isso é o essencial, e depois cresceu com o tempo, porque estamos apenas começando a pensar em como significa desenvolver aplicativos em nuvem com escalabilidade, com confiabilidade e todas essas configurações.

Cloud native começou com esses conceitos e cresceu à medida que mais e mais pessoas começaram a entrar na discussão e trazer seus próprios significados para isso.

Transcrição traduzida de parte do vídeo acima

Então a gente pode pensar em Cloud Native como uma forma de pensar, mais direto ao ponto, mais simples. Projetando para usar os recursos de cloud desde o dia 1, usando da elasticidade da nuvem para entregar benefícios como escalabilidade, resiliência, confiabilidade e uma série de outros recuros.

Cloud Native pode ser definido como pensado para a nuvem, com a nuvem em seu DNA, usando os recursos da nuvem de forma transparente, usual, simples, como se fizesse parte da forma como desenvolvemos, desde sempre.

A entrevista com Brandan continua tocando em um assunto super interessante: Microsserviços. E voltaremos à transcrição dessa parte mais à frente.

Mas agora, é importante entendermos de onde surge o termo Cloud Native, e qual o papel da CNCF e do Kubernetes nesse universo.

A história do CNCF

Em 2014, o Google abriu o código-fonte de um projeto interno chamado Borg, que eles estavam usando para orquestrar contêineres. Não tendo um local para hospedar o projeto, o Google fez uma parceria com a Linux Foundation para criar a Cloud Native Computing Foundation (CNCF), que incentivaria o desenvolvimento e a colaboração do Kubernetes e outras soluções cloud native. A implementação do Borg foi reescrita em Go, renomeada para Kubernetes e doada como o projeto inicial. Ficou claro desde o início que o Kubernetes era apenas o começo e que um enxame de novos projetos se juntaria ao CNCF, estendendo a funcionalidade do Kubernetes.

https://www.cncf.io/blog/2018/11/05/beginners-guide-cncf-landscape/

Por que a CNCF é necessária?

As empresas estão percebendo que precisam ser uma empresa de software, mesmo que não estejam no ramo de software. Por exemplo, o Airbnb está revolucionando o setor de hotelaria e os hotéis mais tradicionais estão lutando para competir. Cloud Native permite que a TI e o software se movam mais rapidamente. A adoção de tecnologias e práticas Cloud Native permite que as empresas criem software internamente, permite que os profissionais de negócios se associem estreitamente ao pessoal de TI, acompanhem os concorrentes e ofereçam melhores serviços a seus clientes. As tecnologias CNCF permitem a portabilidade na nuvem sem lock-in (independente do fornecedor).

https://www.cncf.io/blog/2018/11/05/beginners-guide-cncf-landscape/

Cloud Native só existe para o Kubernetes?

Kubernetes é o projeto que deu origem à CNCF. E óbvio, como um orquestrador, ele já nasce como coração e cabeça do corpo que são os projetos Cloud Native hospedados na CNCF.

Mas Cloud Native é um conceito maior que o próprio Kubernetes. E nada impede que um concorrente ou até mesmo um sucessor do Kubernetes surja nos próximos anos, ou décadas.

A perspectiva Cloud Native entrega essa visão vendor agnostic, desenhado para nuvens públicas, privadas ou híbridas, para o baremetal ou para IoT e Edge computing.

Cloud Native é desenhado para o cenário mais simples, aquele em que não se tem muito dinheiro para muita coisa, até cenários caóticos que beiram o inimaginável.

Porque precisamos de Cloud Native?

Microsserviços está na fundação do Cloud Native. Esse desenho arquitetural é o maior demandante das tecnologias, patterns e soluções que observamos ao redor do cloud native.

E como em qualquer cenário de disrupção, primeiro uma tecnologia é produzida para um nicho, para somente após trazer muito resultado, se popularizar como standard e beneficiar novos projetos.

Eu falei sobre isso no post Sobre Formula 1 e Microsserviços.

O mundo mudou muito nos últimos 10 anos

6 de outubro de 2010 nascia o Instagram, em setembro de 2016 nascia o TikTok, ClubHouse nasceu em 2020 e quase decolou, se não fossem as bateções de cabeça. E há críticas a todos os lados (leitura 1, leitura 2). Minha crítica se dá a respeito das restrições tecnológicas. Os problemas foram grandes na época.

O fato é que nosso mercado, o de tecnologia, está mais exigente, um movimento natural já que estamos cada vez mais conectados. Isso produz novos categorias de demandas, que se traduzem em novas categorias de serviços e produtos que precisam de arquiteturas que comportem essa demanda.

Aqui microsserviço é o desenho da vez.

E é sobre isso que vou falar no post 2 da nossa série sobre cloud native.

No próximo post

No próximo post da série vou abordar como microsserviços e cloud native andam tão próximos…