Liferay as SaaS First

What Liferay's New Model Means and Its Impacts

SaaS First: What Liferay's New Model Means and Its Impacts

The technology world is following the market trend of moving its products to a SaaS (Software as a Service) model, and in today's edition, we will finally understand its real meaning and impact on the Liferay ecosystem.

But first, what exactly is SaaS?

SaaS stands for Software as a Service, and its purpose is to allow users to have direct access to a web application in the cloud.

In our daily lives, we use various SaaS products without even realizing it. Examples include Google products like Gmail and Google Drive, Microsoft's Teams, management tools like Notion or ClickUp, and many others.

It is evident from these examples that in SaaS models, users do not need to worry about anything related to hardware, software, security, availability, or any aspect of technology creation and maintenance.

This is why it is a model that has stood out and is increasingly gaining market share. With this model, the provider saves costs by having a shared infrastructure for all users, who save by not needing their own infrastructure or a technology team and knowledge.

The business model also allows for purchases through a subscription model, with monthly or annual payments, which is also very popular given the growth of subscriptions to newsletters, streaming services, and others.

The advantages of the business model are providing the provider with recurring revenue and allowing the user to pay only for their usage.

SaaS x PaaS x IaaS x On-premise

To understand Liferay's offerings, we need to comprehend the differences between SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a Service), and On-premise.

The "as a Service" models are cloud-based and differ based on the resources managed by the provider. The On-premise model, on the other hand, is when the user manages all resources, starting from the infrastructure.

The image makes it easy to understand: in On-premise, the user manages everything; in IaaS, the user accesses infrastructure via the cloud (AWS, Google Cloud); and in PaaS, the user manages the created application. Examples of PaaS include Microsoft Azure and WordPress.

Understanding where Liferay DXP fits into these models

Now that we understand the cloud models, we can move on to what really interests us: the cloud strategies implemented for Liferay DXP.

The early versions of Liferay didn't even have a graphical interface, let alone a cloud infrastructure available to its clients. But as the world moved toward the cloud, to avoid falling behind, Liferay launched a new product, initially called Liferay Cloud.

The main idea was to eliminate clients' headaches and concerns about infrastructure and portal availability. The development, customizations, and processes we are accustomed to remained, but now it was done in a cloud infrastructure.

For this, the client received access to a web console where they could manage a repository with a Liferay Workspace and its configured CI/CD, access the application server machines, Elasticsearch, database, and everything else.

I have always liked this product. It simplifies the management of different environments (DEV, HML, and PRD), allows high availability and auto-scaling, has performance analysis tools, and is secure. All this without limiting customization actions.

Enter Liferay SaaS, or is it LXC?

About three years ago, another offering was added to Liferay Cloud. Now it would be divided into Liferay SaaS and Liferay PaaS. There was some confusion with the names until they were defined as SaaS and PaaS. Initially, the new SaaS offering was called Liferay Experience Cloud (LXC).

This name caused some confusion because PaaS was also cloud-based. Was it Liferay Cloud? So, the names LXC-SM (Self-managed) for PaaS and Self-Hosted for On-premise were given.

Due to the lack of consistency in the names in the media, the names were confusing, at least for me. But now it is easier to refer to just SaaS, PaaS, and Self-Hosted.

But what is special about Liferay SaaS?

In Liferay SaaS, as we saw earlier, the user is not responsible for managing the application. This means that Liferay must manage everything:

  • Cloud infrastructure

  • Security

  • Portal availability

  • Updates

This allows the client to:

  • Not need to understand the backend technologies used (Java, OSGi, Gradle…)

  • Have their product always updated to the latest version without needing migrations

  • Pay only for the volume they use (accesses and users)

It sounds very good because we know that Liferay's learning curve is not simple and that migrations are a challenging and expensive task.

But what do we have to give up to achieve this? To make product updates feasible, and considering that clients will now share the same infrastructure, Liferay had to block a significant part of the customizations.

What is not available in SaaS?

  • No OSGi modules (MVC portlets, service builder, etc.)

  • No serviceLocator

  • No server administration, and therefore no Groovy or scripting

  • No portal-ext configurations

  • No themes

  • And more…

You can check the compatibility matrix at this link.

All these items are blocked. Any customization to the core or source code would impact other clients on the same infrastructure and make constant updates impossible.

Thus, Liferay had to cut all these. Initially, if you were unaware of this information, you might feel impacted. However, since the launch of SaaS, Liferay has been creating new alternatives to address the problem of losing customization capability.

I would say that the main ones so far are the headless API, Objects, and Client Extensions.

Ecosystem News

Partnership with SugarCRM

This month, Liferay announced a very interesting partnership with SugarCRM. We know that Liferay can function as an integrator and that there are several important CRMs in the market.

An integration with them is always good for the product as a whole and helps convince clients.

New content from Simplify

New content on our blog!

Continuing with our promise not to bring only technical content, we published a blog about digital experiences for the client.

In the link above, you can find examples of digital experiences and how a DXP like Liferay generates value for clients through personalization and integration.

Insight of the Edition

The insight of this edition is "How to make authenticated requests in Liferay." More specifically, I wanted to bring this topic to help us consume the endpoints available in the headless API, one of the novelties that help bypass SaaS restrictions.

The first idea most people have when faced with this problem is to use p_Auth or auth_token. It is a session cookie used to validate your authentication.

There are some ways to obtain this cookie, the main one being through the JavaScript object Liferay and its "authToken" attribute. You can test this directly in your browser console.

Liferay.authToken

It seems very good and easy, but with it alone, it is not possible to make requests from outside the portal, only from within. It is useful when you are making requests in a React portlet, for example.

Now, to make requests from outside the portal, we have two options: Basic Auth and OAuth 2.0. The Basic Auth option is easier and less secure. To use it, just pass the base64 of the email concatenated with the password, separated by a colon.

base64 <<< test@simplifytec.com.br:test

You can find an encoder online or use a terminal command. It should return something like:

dGVzdEBzaW1wbGlmeXRlYy5jb20uYnI6dGVzdA==

Now just pass an Authorization header with your code as follows:

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

Now, to use OAuth 2.0, you first need to register your application as an authorized OAuth client. You can follow this documentation.

After registration, generate your OAuth 2.0 access token, also explained in the documentation, and make your request by passing the following header:

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

If you want to know more about the subject, the following Liferay article has good information.

Thank you for reading this far

I am always open to receiving feedback and topics you would like to see here. Feel free to send me a message on LinkedIn to chat.

Do you need support for your project? Need consultancy or training? Interested in Simplify? Contact us and discover how our expertise in Liferay can help you.

That's all for today. I hope you enjoyed it, and see you next time!
- Guilherme Kfouri