Catch up on Liferay Unconference 2018

Firelay is at DEVCON! How could we not be? In the next blog posts we are going to share what we learned, or what struck us, or what came to our attention. Today, our DevOps Freark and Simon attended the Unconference, and what follows is a recap of some of the talks they joined. 

How do you monitor your Liferay application & plugins

“Meten is weten” (to measure is to know) as they say in the Netherlands. This session covered a range of tools which can be used to monitor your Liferay application. Some of the tools mentioned were Nagios, New Relic, Appdynamics, Dynatrace, Jstack, but also extending or building your own tooling using for instance JMV. However, in the latter case, you should always consider that developing your own tooling may very well be more expensive than forking out for a subscription of a commercial solution.

Liferay migration issues

This talk was quite popular, indicating that a lot of people find migrating Liferay a difficult task.
After hearing all the different issues people had, this feeling was reinforced. Most of the issues seem to centre around content a user-created either in Liferay or through developed plugins.
The steps I’d take are as follows:
Try the automatic tool in a non-live environment. If it works reasonably well then you can fix the existing issues, migrate the plugins and run the migration again. If it doesn’t work easily think if it is possible to start with a clean Liferay or copy past/use API to copy content over.

If it is neither easy nor an option to do a (semi)manual migration then you’ll have to go through the hard migration path and fix issues one at a time until you’re done (possibly with help from Liferay support). When you’re done and you know how to fix everything script this and run it on a fresh dump as well as set up a content freeze. Now you can finally migrate.

Container deploys and upgrades

There seem to be a lot of questions concerning how to run Liferay in containers as well as a lot of ideas.
Some part of this revolves around how licenses work with containers. The issues with licensing and restarting containers are covered by flexible licensing that Liferay offers, allowing to temporarily run more containers than normal.

Another problem with licensing seems to be with regards limits on CPU cores.
To avoid problems with this, either docker hosts need to be small or containers need specific limits set, both giving up some flexibility of containerization.

Another big issue seems to be startup time and warm-up. when making images for containers take good care as to what the state is of the Liferay you’re starting, do you need a completely clean installation or if you need it already with an OSGi state for instance.

DXP vs CE

In a session with the topic DXP vs CE, we discussed the differences and added value of DXP vs CE. The biggest benefit of DXP is the support you will be able to get from Liferay. More frequent bugfixes and security fixes are also a big benefit. However on the downside is that your deployments of Liferay can be less flexible due to license restrictions.

Another interesting “what if” discussion was also initiated based on a fictitious scenario courtesy of Milen Dyankov. What if Liferay was open-core instead of having a separate CE and DXP versions. In this scenario, Liferay would only charge based on a support subscription model and some non-free marketplace modules, but otherwise, there would only be one version of Liferay. Interestingly many participants felt that this different paradigm would not matter very much to their customers. At any rate, this was an interesting different reality to ponder about.