A tecnologia está cada vez mais presente em nossas vidas e em todos os lugares, fazendo com que negócios estejam cada vez mais integrados entre os usuários e as aplicações. Em um mundo cada vez mais conectado, desafios como escalabilidade, produtividade e entrega rápida de qualidade, estão cada vez mais presentes em qualquer empresa, uma vez que, segundo a Forbes, todas as empresas são de software. Para tornar tudo isso possível, novos conceitos são criados, dentre eles, o cloud e o microservices, que vem se tornando expressões cada vez mais corriqueiras nas reuniões de arquitetura. Então, surge a seguinte pergunta: Será que o Java está preparado para lidar com esses diversos conceitos em um ambiente corporativo? A resposta é sim.
Nos últimos anos, a Eclipse Foundation vem conduzindo esse desafio em conjunto com outros membros da comunidade, além de diversas empresas do setor, para fazer o mundo Java cada vez mais atualizado e preparado, tanto para microservices, quanto para utilizar os recursos cloud. Dentre os esforços, podemos citar o Jakarta EE, que é o novo lar do Java EE, que tem como objetivo ser cloud native, além do Eclipse MicroProfile, que é uma plataforma otimizada para lidar com arquiteturas de microservices.
O que é a nuvem?
O software está em toda parte. Não importa para onde olhamos, há um software em execução. Na história humana, vimos o número de máquinas/software aumentar com o tempo, de uma máquina compartilhada por várias pessoas a uma única pessoa usando milhares de programas de software. Agora, podemos ver o software interagindo com outro, como quando compramos uma passagem aérea: Um sistema envia um email, outro lê e dispara um evento em nosso calendário. Essa nova abordagem abre mais perspectivas e oportunidades de negócios para todos, incluindo o aprendizado de máquina. Não se engane, a Skynet está chegando em breve.
O nascimento do Agile
Não é apenas a quantidade de software que aumentou, mas também o número de interações nos programas. Mais usuários, mais requisitos, mais feedback. Não faz sentido esperar anos para lançar um produto, o tempo de colocação no mercado e o feedback do usuário são vitais para conduzir o produto na direção certa. Por isso, em 2001, um pequeno grupo de pessoas, cansado da abordagem tradicional de gerenciar projetos de desenvolvimento de software, projetou o Manifesto Agile, que deu origem à metodologia Agile.
O Agile é um processo que ajuda as equipes a fornecer respostas rápidas e imprevisíveis usando o feedback que recebem do projeto. Cria oportunidades para avaliar a direção de um projeto durante o ciclo de desenvolvimento. As empresas avaliam o projeto em reuniões regulares chamadas sprints ou iterações. Em um aspecto mais técnico alinhado ao Agile, a abordagem DDD (Domain-Driven Design) ajuda a desenvolver softwares focados nas necessidades complexas que conectam profundamente a implementação a um modelo em evolução dos principais conceitos de negócios. Técnicas como a linguagem ubíqua são usadas para ter o código mais próximo do negócio, diminuindo a barreira entre o desenvolvedor e o usuário e, portanto, tendo mais interações do que com o desenvolvimento ágil.
Microservices
Cada vez mais empresas entendem que todas as empresas são empresas de software. Como resultado, dependem fortemente dos softwares, e frequentemente precisam contratar desenvolvedores de software. Surge então a questão de como lidar com várias pessoas que trabalham em apenas um projeto. Para resolver essa nova questão, podemos olhar para uma antiga estratégia militar romana: Dividir e conquistar. Sim, dívida uma questão altamente complexa em pequenos blocos de problemas, dívida a equipe em pequenos grupos e divida o projeto monolítico em vários pequenos projetos. O estilo arquitetural de microservice é uma abordagem para o desenvolvimento de uma única aplicação em um conjunto de pequenos serviços, para que, ao invés de uma empresa de comércio eletrônico trabalhar com apenas uma base de código e uma implementação, possa dividir as equipes/código em financeiro, estoque de produtos, marketing e assim por diante. Uma coisa a salientar, o contexto DDD ainda está lá. De fato, ele trabalha junto com a abordagem de como criar serviços úteis com base em alguns de seus conceitos limitados. Não estamos descartando ou deixando de lado essa noção, mas agregando-a em microservices.
Os microservices, além de tornar a equipe mais ágil, também trazem várias vantagens, como expansão independente e liberação de serviços discretos. No entanto, ele carrega algumas desvantagens no lado das operações. O código finalizado não é suficiente se não for para produção. Portanto, as operações devem seguir a equipe de desenvolvimento para liberar o que o sistema precisa implantar todos os dias. É por isso que: O DevOps é um conjunto de práticas de desenvolvimento de software que combinam operações de desenvolvimento de software (Dev) e operações de tecnologia da informação (Ops) para reduzir o ciclo de vida de desenvolvimento de sistemas, ao mesmo tempo em que fornecem recursos, correções e atualizações com frequência em alinhamento com os objetivos dos negócios.
Com as equipes de desenvolvimento e operações integradas e trabalhando em conjunto com a metodologia DevOps, estamos prontos para lidar com software e suas operações. Mas e o hardware? Integrar a equipe significa que o equipamento não existe. O que acontece quando uma equipe precisa de mais processamento do computador? Faz sentido alguém comprar um novo servidor? Não é rápido o suficiente. No mercado global e com a batalha de milissegundos para obter menos tempo de resposta, um servidor mais próximo do cliente significa menos tempo de produção, mas como compramos/mantemos os servidores em vários continentes?
Com a computação em nuvem disponível sob demanda para recursos de sistema de computador, especialmente armazenamento de dados e poder de computação, sem gerenciamento ativo direto do usuário, a computação em nuvem significa: Não nos importamos com o próprio hardware. Esses serviços são amplamente divididos em três categorias: Infraestrutura como Serviço (IaaS), Plataforma como Serviço (PaaS) e Software como Serviço (SaaS).
Essas categorias trazem um novo conceito de negócio ao mercado. Além disso, cada serviço traz novas instalações, principalmente de entrega rápida.
Benefícios do IaaS
- Não há necessidade de investir em próprio hardware;
- Escala de infraestrutura sob demanda para suportar cargas de trabalho dinâmicas.
Benefícios do PaaS:
- Desenvolva aplicações e chegue ao mercado mais rapidamente;
- Reduza a complexidade com o middleware como serviço.
Benefícios do SaaS:
- Aplicações e dados são acessíveis a partir de qualquer computador conectado;
- Nenhum dado será perdido se o laptop quebrar porque as informações estão na nuvem.
Um projeto de software precisa possuir entrega rápida como a melhor abordagem estratégica. Uma entrega rápida traz vários benefícios, como receber feedback, corrigir bugs e principalmente conduzir o produto na direção certa, com base nas necessidades do usuário. É por isso que várias metodologias e tecnologias como Agile, microservices, DevOps e a nuvem, nasceram. Hoje em dia, é difícil pensar em esperar um ano para lançar um projeto, correndo o risco de perder o timing do mercado. A comunidade Java decidiu lançar um release a cada seis meses, e o Jakarta EE busca o mesmo caminho. O Platform.sh tem o objetivo de facilitar a transferência do projeto para a computação em nuvem, permitindo a implantação em qualquer lugar e a qualquer hora, inclusive em uma sexta-feira ensolarada.
O que é o Cloud Native?
A computação em nuvem trouxe muitas metodologias e técnicas que revolucionaram os mundos comercial e técnico. Entre os termos que surgiram, nasceu o cloud native. Para atender e cobrir essas expectativas no universo Java, nasceu o Jakarta EE.
Como qualquer novo conceito, existem vários conceitos com o mesmo nome. Se lermos os livros ou artigos sobre cloud native, poderemos não encontrar consenso sobre o termo. Por exemplo:
"Cloud-native é uma abordagem para criar e executar aplicações que explora as vantagens do modelo de computação em nuvem". -Pivotal
"Cloud-native é uma maneira diferente de pensar e raciocinar sobre sistemas de software. Ele incorpora os seguintes conceitos: Alimentado por infraestrutura descartável, composta por limites, escalas globalmente, adota a arquitetura descartável". - Architecting Cloud Native Applications
"De maneira geral, "cloud-native" é uma abordagem para criar e executar aplicações que explora as vantagens do modelo de entrega de computação em nuvem. "Cloud-native" é sobre como os aplicações são criados e implantados, não onde." - InfoWorld
"As tecnologias cloud-native capacitam as empresas a criar e executar aplicações escaláveis em ambientes modernos e dinâmicos, como públicos, privados, e nuvens híbridas. Containers, service meshes, microservices, infraestrutura imutável e APIs declarativas exemplificam essa abordagem"
Cloud-Native Computing Foundation
Uma abordagem que gosto é que uso com base nesses livros e artigos é:
Um conjunto de boas práticas para otimizar uma aplicação na nuvem por meio de:
- Containerização;
- Orquestração;
- Automação.
Em um consenso mútuo em torno das definições de vários artigos, podemos dizer que o cloud native é um termo usado para descrever ambientes baseados em containers. Portanto, o cloud native não está relacionado a linguagens ou estruturas de programação específicas ou mesmo a uma empresa provedora de nuvem, mas a containers, porém, não limitado a isso.
O que são as melhores práticas do cloud native?
Quando começamos a aprender um novo conceito, geralmente corremos para ler sobre as práticas recomendadas para evitar erros e qualquer code smell. Com a Programação Orientada a Objetos (POO), temos os padrões do gang of four, e no Java, temos o Effective Java e, ao falar sobre arquitetura, temos o Código Limpo e a Arquitetura Limpa. Portanto, a pergunta é: Quais são as melhores práticas para o cloud native?
Até onde sabemos, não existem práticas recomendadas relacionadas especificamente ao cloud native. Mas como a nuvem está próxima da metodologia Agile, há várias práticas que podemos aproveitar para ter uma aplicação saudável e indolor:
- Manifesto para desenvolvimento ágil de software;
- Integração contínua;
- Entrega contínua;
- Design orientado a domínio, DDD.
As práticas mais conhecidas relacionadas a qualquer aplicação que inclua computação em nuvem são inspiradas nos padrões de arquitetura e refatoração de aplicações corporativas de Martin Fowler.
The Twelve-Factor App
Em resumo, ainda não existem práticas específicas recomendadas para o cloud native, mas existem padrões do Agile, microservices e a aplicação dos doze fatores que são úteis para seguirmos.
Olá mundo com Payara Micro e Platform.sh
Nesta seção, mostraremos como criar o nosso primeiro projeto REST com o Payara Micro e, em seguida, como mover esse projeto para o Platform.sh usando o Maven Archetype, que é um kit de ferramentas de modelagem de projeto Maven. Um arquétipo é definido como um padrão ou modelo original a partir do qual todas as outras coisas do mesmo tipo são feitas. Podemos gerá-lo com o seguinte comando:
mvn archetype:generate -DarchetypeGroupId=sh.platform.archetype -DarchetypeArtifactId=payara -DarchetypeVersion=0.0.1 -DgroupId=my.company -DartifactId=hello -Dversion=0.0.1 -DinteractiveMode=false
O próximo passo é convertê-lo em um projeto Git, portanto:
cd hello
git init
git add .
git commit -m "hello world with Payara"
Finalmente, vamos criar um novo projeto no Platform.sh, pegue o endereço do repositório git e envie o código para o mestre. Assim que fizemos o push do código para o domínio, será gerará os containers necessários para disponibilizar a nossa aplicação.
git remote add cloud <platform.sh-git-address>
git push cloud master
Assim que fizermos o push do código para removê-lo, o mesmo criará a compilação do Maven e implantará a aplicação. No final, será gerado o endereço IP, que será pego por esse endereço e será feito uma solicitação no servidor.
curl <ip_server>
hello from Platform.sh
O arquétipo do Maven que geraremos inclui as dependências do Maven e os três arquivos que o Platform.sh requer para mover essa aplicação para a nuvem. Agora, vamos aprofundar este arquivo e falar sobre os componentes, um por um. Para explicar melhor, esses arquivos representam o conceito de infraestrutura como código, ou seja, o processo de gerenciar e provisionar data centers de computadores por meio de arquivos de definição legíveis por máquina.
name: app
type: "java:8"
disk: 1024
hooks:
build: mvn -DskipTests clean package payara-micro:bundle
web:
commands:
start: java -jar -Xmx512m target/microprofile-microbundle.jar --port $PORT
O arquivo da aplicação possui a configuração para criar o container da aplicação. A construção é definida por um comando Maven que cria um uberjar. Para criar o container da aplicação, o arquivo possui os seguintes atributos:
- nome (obrigatório) - define o nome exclusivo do container da aplicação;
- tipo (obrigatório) - define a imagem base do container a ser utilizada, incluindo o idioma da aplicação e sua versão;
- disco e montagens (obrigatório) - Define os diretórios de arquivos graváveis para a aplicação;
- Construção e dependências- Controla como a aplicação é compilada. Precisamos observar que essas compilações ocorrem antes que a aplicação seja copiada em diferentes instâncias. Portanto, todas as etapas aqui serão aplicadas a todas as instâncias da web e local;
- web - Controla como a aplicação da web é servida.
Muito mais!
Platform.sh e Payara criaram um guia útil para falar sobre Jakarta EE e cloud native.
Nesse guia teremos;
- Definições de cloud-native
- Hello World com Payara Micro e Platform.sh
- Payara Platform com JPA
- Payara Platform com NoSQL
- Payara Micro, Platform.sh e Microservices
Clique no link para saber mais: https://www.payara.fish/page/payara-platform-and-paas-with-platform-sh/
Com isso foi possível criar uma aplicação Jakarta EE e movê la para nuvem de uma maneira bastante simples e sem se preocupar com toda a complexidade de infraestrutura. Como já mencionamos, apesar de existirem diversos artigos, livros e uma fundação, ainda não existe uma versão "final" definindo o cloud-native, porém, muitas empresas, comunidades e indivíduos estão trabalhando e focando em criar aplicações que tiram cada vez mais proveito da aplicação em nuvem. Um ponto muito interessante desse livro que reúne vários conceitos e práticas para confirmar que é possível criar uma aplicação cloud-native através to Payara e com Platform.sh.
Sobre o autor
Otávio Santana é engenheiro de software, com grande experiência em desenvolvimento opensource, com diversas contribuições ao JBoss Weld, Hibernate, Apache Commons e outros projetos. Focado em desenvolvimento poliglota e aplicações de alto desempenho, Otávio trabalhou em grandes projetos nas áreas de finanças, governo, mídias sociais e e-commerce. Membro do comitê executivo do JCP e de vários Expert Groups de JSRs, é também Java Champion e recebeu os prêmios JCP Outstanding Award e Duke's Choice Award.