Liferay comes with so many features that it's hard to judge when a feature is a good solution for a given problem. I'd like to shine some light onto some of these features and common misconceptions about them because it's easy to abuse them for purposes for which they're not well suited - despite making the impression they might.
CC BY-ND 2.0 by S. Benno

Today I'm starting with Liferay Instances.

TL;DR? Skip to the last paragraph, giving the common "wrong problems" that instances are used to solve. While they are a great feature, they don't necessarily solve all of the problems they get thrown at in the expected way.

What is an instance?

If you go to Control Panel / Configuration / Portal Instances, you'll find the list of available instances and can add more. A new instance is introducing a totally separate data area - you'll have a new user database, new content, new sites etc. They have nothing in common with the other instances that you have in the portal. Nothing? Well, they share the same application server - so at least the portlets and plugins are shared, and naturally the maintenance intervals & downtime. But, on the data side: Nothing.

As you would expect, Liferay starts with a single instance that is used to handle all requests. Only if you actively introduce a second instance, you'll use multiple instances. The reason for this is that instances are detected through the server name: If you connect to the server depicted above with spaceprogram.liferay.com, the server will serve with the content of the second instance. All hostnames that can't be associated will be handled by the default instance.

This is called multi-tenancy. You may have multiple portals on a single application server. Great, isn't it?

Using Multiple Instances

Now assume you're providing services for multiple customers. You have your first customer's portal running at customer1.example.com in the first instance and you'd like to add customer2.example.com as a completely separated portal: Neither the content, nor the user administration should interfere with each other.

On first sight, you'd easily just introduce another instance named customer2.example.com and populate it with the required data - done. Two customers, two instances.

That was too easy, wasn't it? Where's the shortcoming?

Well, you'll end up with two instances with different features - one is more special than the other

Different features?

The first instance on Liferay is a special instance: It enables you to administer the application server (garbage collection, reindex search index, show memory consumption), install new plugins, access marketplace, etc.

Compare this part of the Control Panel of the first instance

with the same part of the second instance: You'll easily see that all of the server administration, application installation etc. is only to be found on the very first instance. (I promise that I'm logged in as Administrator on both instances).

As long as your first customer is not more special than your second one (and allowed to administer infrastructure for all of them), you might want to limit yourself to a particular different use of instances:

Make the first instance a purely administrative instance, e.g. administration.example.com. Then add all of your customer's sites as secondary (tertiary etc) instances. You'll end up with n+1 instances. The default instance should only have a few administrative users, while the other instances have whatever those instances need.

Now your first instance's administrators can maintain the whole site while your customer's administrators can't install server side plugins and maintain them - great, because the plugins are always available to all other sites, and they might not even know whom they share the server with. Imagine your customer1 to update customer2's theme... (see comments below)

Commonalities and Differences

Remember, all instances still share the same server. If one of the instances is really busy, the performance of the others might go down with it. If one requires downtime for updating a component, the others will go down with it. If one of the customers needs a specific plugin to be deployed, all of the customers will get it.

On a firewall level: If one of the instances needs access to a particular backend system (of customer1), connections to it will originate "at Liferay", thus no firewall can detect which instance the connection is coming from.

Separating instances

What happens when - some time in the future - you want to separate the instances from each other? If you follow my suggestion to have an administrative instance as first instance, life is (relatively) easy: Create a copy of your whole portal (all instances) and delete all the unused customer's instances from each of the instances. You'll end up with two portal servers with an administrative instance (which is a copy of each other).

Everything well? Or the wrong problem or the wrong solution?

Shiny, huh? But do instances solve all of your problems?

They can easily simulate to solve them. But they can also trick you into believing that they're a good solution. More often than not they aren't. Let's look at some shortcomings and issues that you should be aware of:

• You'll have to administer each Instance as if it was a new portal: User Management, Single Sign On, User Profiles, Groups, Roles, Templates, ADTs, everything. If you update any in one instance, they won't be updated in the others. This might be what you expect, or it might be doubling your work. Typically it's some of both.
• All instances share the same plugins (and their versions). If your customers use plugins that contain business logic specifically for them, this business logic might accidentally be published on other customer's instances. Themes and Hooks are shared between all instances as well - don't select your customer1-theme for the sites of customer2. Check the comments: You can limit your theme to specific instances
• If one of your instances is really popular and draws a lot of traffic (enough to slow down the site), the other instances will also suffer performance and your customers might not be happy if you can't quickly serve their few web visitors.
• If you need to cluster one instance, you must cluster all of them. Liferay's caches need to be dimensioned properly to serve the commonly requested content for all instances.
• Some of Liferay's content types (e.g. ADTs, Web Content Templates) execute server side code. When these are done inappropriately, they might make it possible for customers to access other instance's data. You'll need to trust the individual Administrators with permissions to edit these content types to not do harm to others.
• Instances always assume that you can predetermine the host names that users are using. You should not make your administrative site available to the internet as "the default" when you don't know the host. Thus there's some extra work that IMHO requires a webserver in front of the appserver. But that's good practice anyway.

Did I forget something?

Did this discourage you from using instances? It shouldn't - it just should help you make an informed decision when you consider using them and how.