SaaS First, o que o novo modelo da Liferay significa e seus impactos

O mundo da tecnologia vem seguindo a tendência de mercado de mover seus produtos para um modelo SaaS (Software as a Service) e na edição de hoje iremos entender de uma vez por todas o seu real significado e impacto no Ecossistema Liferay.

Mas primeiro, o que é de fato um SaaS?

SaaS significa Software as a Service, ou Software como Serviço, e o intuito dele é permitir aos usuários terem acesso direto à uma aplicação web em nuvem.

No dia-a-dia utilizamos diversos SaaS’s sem nos darmos conta. Exemplos são produtos da Google como Gmail e Google Drive, o Teams da Microsoft, ferramentas de gestão como Notion ou Clickup e muitos outros.

Fica evidente observando os exemplos que em modelos SaaS o usuário não precisa se preocupar com nada relacionado a hardware, software, segurança, disponibilidade ou qualquer aspecto da criação e manutenção da tecnologia.

Por isso, é um modelo que se destacou e vem conquistando cada vez mais mercado. A partir desse modelo, o provedor economiza custos ao ter uma infraestrutura compartilhada para todos os usuários, que economizam em não precisar de uma infraestrutura própria ou de conhecimento e time de tecnologia.

O modelo de negócio também permite a compra através de um modelo de subscrição, com pagamentos mensais ou anuais, que também está super em alta dado o crescimento de subscrições de newsletters, streamings e outros.

As vantagens do modelo de negócio são proporcionar ao provedor uma receita recorrente e ao usuário pagar apenas por sua utilização.

SaaS x PaaS x IaaS x On-premise

Para entendermos as ofertas da Liferay precisamos compreender as diferenças entre SaaS, PaaS (Platform as a Service), IaaS (Infrastructure as a Service) e On-premise.

Os modelos “as a Service” são modelos em nuvem e se diferem pelos recursos que são gerenciados pelo provedor. Já o modelo On-premise é quando o usuário gerencia todos os recursos desde a infraestrutura.

Pela imagem fica fácil de entender. On-premise o usuário gerencia tudo, no IaaS o usuário acesso por nuvem a infraestrutura (AWS, Google Cloud) e no PaaS o usuário gerencia a aplicação criada. Exemplos de PaaS são o Microsoft Azure e Wordpress.

Entendendo onde o Liferay DXP entra nesses modelos

Agora que entendemos os modelos em nuvem podemos passar para o que realmente nos interessa, as estratégias de nuvem implementadas para o Liferay DXP.

As primeiros versões do Liferay não possuíam nem interface gráfica, quem dirá uma infraestrutura cloud disponível para seus clientes. Mas o mundo evoluiu em direção à nuvem e para não ficar para trás, a Liferay lançou um novo produto, na época chamado apenas de Liferay Cloud.

A ideia principal dele era eliminar as dores de cabeça e preocupações dos clientes com infraestrutura e disponibilidade do portal. O desenvolvimento, as customizações e os processos que estamos acostumados se matinham, porém, agora era feito em uma infraestrutura em Cloud.

Para isso, o cliente recebia acesso à um console web onde poderia gerenciar um repositório com um Workspace Liferay e seus módulos e CI/CD configurado, acessar as máquinas do servidor de aplicação, elastic search e banco e todo o resto.

Sempre gostei muito desse produto. Ele facilita o gerenciamento de diferentes ambientes (DEV, HML e PRD), permite alta disponibilidade e auto-scaling, possui ferramentas de análise de desempenho e é seguro. Tudo isso sem limitar as ações de customizações.

Entra o Liferay SaaS, ou será LXC?

Há cerca de 3 anos, foi adicionada mais uma oferta para o Liferay Cloud. Agora ele seria dividido em Liferay SaaS e Liferay PaaS. Houve uma certa confusão com os nomes até eles serem definidos em SaaS e PaaS. Inicialmente foi dado o nome de Liferay Experience Cloud (LXC) para a nova oferta que seria um SaaS.

Esse nome causou algumas confusões, pois, o PaaS também era Cloud, seria ele o Liferay Cloud? Então foi dado o nome de LXC-SM (Self managed) para o PaaS e Self-Hosted para o On-premise.

Por não ter uma conformidade dos nomes nos meios de comunicação, os nomes ficaram confusos, pelo menos para mim. Mas agora está mais fácil se referindo apenas à SaaS, PaaS e Self-Hosted.

Mas o que o Liferay SaaS tem de especial?

No Liferay SaaS, como vimos anteriormente, o usuário não é responsável por gerenciar a aplicação. Isso significa que a Liferay deve gerenciar tudo:

• Infraestrutura em nuvem

• Segurança

• Disponibilidade do portal

• Atualizações

Isso permite que o cliente:

• Não precise entender das tecnologias utilizadas no backend (Java, OSGi, Gradle…)

• Tenha seu produto sempre atualizado na última versão sem precisar fazer migrações

• Pague apenas pelo volume que utilizar (acessos e usuários)

Parece muito bom, afinal de contas, sabemos que a curva de aprendizado do Liferay não é simples e que migrações são uma tarefa árdua e cara.

Mas o que precisamos abdicar para conseguir isso? Para viabilizar principalmente as atualizações do produto, e levando em consideração que agora clientes dividirão uma mesma infraestrutura, a Liferay precisou bloquear grande parte das customizações.

O que não temos no SaaS?

• Sem módulos OSGi (MVC portlets, service builder e etc)

• Sem serviceLocator

• Sem Administração do servidor e com isso sem groovy ou script

• Sem configurações no portal-ext

• Sem temas

• E outros…

Você pode acompanhar a matrix de compatibilidade neste link.

Todos esses itens passam a ser bloqueados. Qualquer customização ao core ou código fonte iria impactar tanto outros clientes que estão na mesma infraestrutura quanto impossibilitaria as atualizações constantes.

Sendo assim, a Liferay precisou cortar todos. De início se você não sabia dessa informação pode se sentir impactado, porém, desde o lançamento do SaaS a Liferay vem criando novas alternativas para contornar o problema de perder essa capacidade de customização.

Eu diria que as principais até o momento são a API headless, os Objects e o Client Extensions.

Notícias sobre o ecossistema

Parceria com o SugarCRM

A Liferay publicou este mês uma parceria muito interessante com a SugarCRM. Sabemos que o Liferay pode funcionar como um integrador e que existem diversos CRMs importantes no mercado.

Uma integração com eles é sempre bom para o produto como um todo e ajuda na hora de convencer clientes.

Novos conteúdos da Simplify

Novos conteúdos em nosso blog!

Seguindo com nossa promessa de não trazer apenas conteúdos técnicos, publicamos um blog sobre experiências digitais para o cliente.

No link acima você confere exemplos de experiências digitais e como um DXP como o Liferay gera valor para os clientes através da personalização e integração.

Novidades no YouTube da Simplify

Sempre recebemos muitos pedidos para voltarmos com os vídeos no YouTube e dessa vez finalmente trago as boas notícias, temos vídeo novo no canal!

Corre lá para saber tudo sobre a Collection Display e como criar um carrossel utilizando a biblioteca Swiper. Não esquece de deixar o link e colocar suas dúvidas nos comentários.

A tragédia no Rio Grande do Sul deixou todo mundo chocado e entristecido. Este espaço é voltado para compartilhar campanhas e ações que irão ajudar a crise que devasta a população gaúcha

Insight da vez

O insight da vez dessa edição é Como fazer requisições autenticadas no Liferay. Mais especificamente quis trazer esse tema para conseguirmos consumir os endpoints disponíveis na API Headless, uma das novidades que ajudam a contornar os bloqueios do SaaS.

A primeira ideia que a maioria das pessoas têm ao se deparar com esse problema é utilizar o p_Auth ou auth_token. Ele é um cookie de sessão utilizado para validar sua autenticação.

Existem algumas maneiras de obter esse cookie, a principal é pelo objeto javascript Liferay e seu atributo “authToken”. Você consegue fazer este teste direto no console do seu navegador.

Liferay.authToken

Parece muito bom e fácil, porém, apenas com ele não é possível fazer requisições de fora do portal, apenas de dentro. Ele é útil quando você está fazendo requisições em um portlet React, por exemplo.

Agora para fazer requisições de fora do portal temos duas opções, Basic Auth e OAuth 2.0. A opção de Basic Auth é mais fácil e menos segura. Para utilizá-la basta passar o base64 do email concatenado com a senha, separados por um ponto e vírgula.

base64 <<< [email protected]:test

Você pode procurar online um Encoder ou utilizar algum comando em um terminal. le deve retornar algo como:

dGVzdEBzaW1wbGlmeXRlYy5jb20uYnI6dGVzdA==

Agora basta passar um header de Authorization com o seu código da seguinte forma:

curl -H "Authorization: Basic dGVzdEBzaW1wbGlmeXRlYy5jb20uYnI6dGVzdA==" http://localhost:8080/o/headless-delivery/v1.0/sites/{siteId}/blog-postings/

Agora para utilizarmos do OAuth 2.0 é necessário primeiro registrar sua aplicação como um cliente OAuth autorizado. Para isso você pode seguir a esta documentação.

Após o cadastro, gere seu token de acesso OAuth 2.0, também explicado como na documentação, e faça sua requisição passando o seguinte header:

curl -H "Authorization: Bearer d5571ff781dc555415c478872f0755c773fa159" http://localhost:8080/o/headless-delivery/v1.0/sites/{siteId}/blog-postings/

Se quiser saber mais sobre o assunto, o seguinte artigo da Liferay possui boas informações.