Liferay: In A Serverless and Microservices Era
Category : Liferay , Microservices , Serverless
In the era of microservices and serverless architecture, it is essential to evaluate if you need to build or buy a software. A decade ago, there was still a lot of push back against virtual machines (VMs) for production servers as they were considered the cause of performance issues. One easy solution at that time was to scale vertically by adding more vCPU and memory. That is not the case anymore. Organizations have not only adopted virtual machines, they are also moving towards containers and serverless. Applications don’t have to be built and deployed as a massive piece of software anymore.
Modular Monolith
As tech giants were sharpening their skills related to microservices, containers and serverless, most businesses were still struggling with modular monolithic applications. The reason they are called modular monolith is because the applications are written as modules but deployed as a monolith.
How can you tell if you are running a modular monolith? In order to figure that out, you should evaluate a few points. The first is that if you are upgrading the application, all the services will be down during that process. The second is that if you need to scale parts of your application, you have to scale the whole application server. One more indicator that you should pay attention to is that your application demands that you use certain programming languages and constructs.
Trend
As of now, many businesses have adopted or are considering their options with microservices and serverless architecture. They do have their own challenges when it comes to orchestration, monitoring and management. It is a different problem to deal with than with the traditional modular monolithic applications. Many tools make it easy to deal with microservices and serverless architecture. Several of them support a single CLI command to deploy the changes to any environment. In the serverless area, Amazon has its own AWS SAM CLI while Serverless, Inc has a serverless framework.
Cloud technologies adoption is becoming common in sectors such as government, healthcare and payment card industries.
What Are We Solving? Is There A Business Driver?
The goal is not to adopt technology for technology’s sake. The goal should be to solve the business need in a cost-effective and timely manner while meeting the demands of ever-changing requirements. We need agility and speed while simultaneously running a highly available application. It is important to keep our eyes on the goal. If a modular monolith solves your need really well, you may want to keep it. But let’s not allow the love for our legacy applications keep us away from innovating in business and technology.
How Do We Adopt?
Adoption takes time. It does not have to be an all or nothing approach. The best way to start is to explore the options for some parts of your application. If you have to parse documents, scan documents, analyze text or video etc., it may be better to externalize those to use the serverless offerings than to deploy and manage those services yourself. Traditionally applications will run command-line tools in the same application server to perform a whole bunch of tasks. The issue with this approach is that you are forced to scale the whole application layer when you have to scale these other processes that are competing for the same resources. A piecemeal approach may be a good starting point.
Is Liferay a Modular Monolith?
The above prelude is important for the following discussion. It is very likely that some of the readers may not even have heard about Liferay. Liferay is a Java based digital experience product that is primarily used to build intranets, customer portals, dashboards and public facing sites. As a product, Liferay has been around for more than 15 years. I have spent more than a decade with Liferay since I was introduced to it in early 2007.
Liferay has evolved over the past decade, yet it may fundamentally look the same when it comes to the deployment architecture. Let’s quickly go over a few points:
- Search. A decade ago Liferay was using Lucene by default and supported Solr and other engines for search and index of documents. Now it uses elastic search by default while providing support for Solr.
- Database. Liferay runs on a relational database, but you could develop applications (portlets) that use their own datasources. This remains the same since founding. Liferay did remove some of the supports for database sharding at application level.
- Deployment Architecture. In a high availability environment, Liferay instances are deployed as clusters with all the instances sharing the same database and data storage. Plugins that are developed can share the same database or connect to external services and databases. The major change for enterprise customers is that Liferay has recently started supporting the elastic licensing model where you could increase and decrease the number of instances while paying only for the additional time. In earlier versions the request for license was through a ticketing system. This has changed since the introduction and evolution of the Liferay Connected Services plugin.
- Vertical Scaling. It is very common for Liferay installation to demand a more powerful application server configuration as a lot of heavy lifting happens at this layer. As an example, all the document parsing, conversion etc. happens in the application server and only the indexed document is pushed to the search engine. Also, all the content images that are being stored are rendered and cached at the application server layer. It is technically possible to externalize the cache with external caches.
- Plugin Portlet Development. Portlets are generally written in Java or a few Java frameworks such as Spring MVC, JSF etc. In the latest version of Liferay, you can write portlets using Javascript frameworks such as React, Angular etc. Liferay supports bundling the JS application and deploying it to the server or running it as standalone JS application using Liferay remote services. It may be very convenient to bundle all the Javascript and deploy it to the application server. Deploying in such a manner means your application server is also the web server serving a lot of Javascript and CSS.
- Services. Liferay has supported exposing the remote services via SOAP, JSON APIs for a long time now.
Various aspects of Liferay have evolved over the past decade, yet it may fundamentally look the same at a high level. Liferay deployments resemble more of a modular monolithic application when it comes to scaling and upgrade. Is there a way to address some of the concerns?
Microsites As An Option
One way Liferay solves some of the scalability and availability needs is via microsite architecture. As an example, we can see how Liferay addresses their own needs. Liferay.com probably started as a single application server which later evolved into a cluster. Various needs for separation of content and access were provided through communities and memberships in a single application cluster. One disadvantage with this approach is that you have to scale the whole system vertically and horizontally to support the growing user base. Another major challenge with a single application cluster is that an upgrade will affect all types of users, sites, and communities.
One way to solve the scalability and upgradability challenge is to run separate clusters of various microsites such as help.liferay.com, web.liferay.com, partner.liferay.com, community.liferay.com, dev.liferay.com etc. They all are tied together via SSO, but exist independent of each other. Typically, if your departments are big, they may want to manage and upgrade their own microsites. This would result in multiple versions of Liferay running within the same organization. This could result in the creation of the very silos that organizations are wanting to prevent. As we all know, the organization’s culture will reflect in the way the teams talk to each other.
Build Or Buy
If you have the capability to develop greenfield applications, you should definitely look into your options that are not constrained by a platform. Do you need a blog or are you trying to build a site like https://medium.com? Is your need for service easily fulfilled by an existing platform or do you have to customize the platform heavily?
It all depends on your business needs. If you are going to spend a significant amount of time and money to customize a product, it may be worth looking into building greenfield applications. Also you could take a hybrid approach where your application leverages functions as a service and other serverless features as needed. If your application has a need to export a lot of files as part of the regular use, it would be wise to run this zip process in an AWS Lambda function or as a separate microservice in an asynchronous way. Running such processes in an asynchronous way within the same application server may not be suitable for your use case. It is better to free up your application server resources so that it can better serve other requests.
What’s Next?
I wish I could cover everything in a single article. But that would become a modular monolithic article. I hope to cover more on this topic in future articles. If there is something that interests you specifically, please comment.
Published: May 22, 2019
