Adobe Experience Manager Sites & More

juan_perotti · 10/15/15

Hi, I'm facing the deployment to the production environment of a CQ project, I have two question I would like to ask to make sure I'm taking the right approach.

1) Reading CQ reference documentation I'm not sure what is best for a production instance, CQ standalone jar or the war version deployed into an application server. Any drawbacks on this approaches? which one could be best?

2) I will need a CDN to boost the site, do you have any reference about Akmai - CQ integration that I could check?

Thanks in Advance!

Ove_Lindström · 10/15/15

Hi Juan,

without knowing more about your project, I first have to ask a couple of questions.

First, if you are close to a "go live" in the production environment, in what kind of environment have you been developing and testing your application to this point?

My opinion is that you should always try to develop, deploy and test as production like as possible. If you need an application server for any reason in the production environment, then your development, system test and acceptance test environment should be setup in the same way. There is a huge risk of getting into trouble otherwise.

Second, to try to "answer" your question, do you need any other functionality that requires an application server in order to deliver your solution?

I have come across some functionality from other third party vendors that configures and integrates nicely in an application server environment but does not have a nice OSGi enabled binary. Then we would have to do quite a lot of "magic" to make it work and get limited support. If you don't have anything like that, less is always more. Go for the standalone version. You can always migrate your repository later.

To your CDN question. As far as I know, there are no OOTB Akamai to CQ integration. It is standard CDN work here. Some things that you should have in mind is what parts of the site that is long term and what is short term. You would like to be able to purge everything under /etc/design/ separately so that you can clear out all cached css and client library file from the CDN when you do a new deployment. More static files, such as /content/dam is not something you would clear every time you release something.

Then you need to take in consideration how you should handle re-activation of already cached URL:s. Is it enough that a new page appears in the CDN after the stipulated time to live (TTL) or do we need to send a purge message. All CDNs I have worked with have this kind of purge API that can be used, but you have to figure out what would trigger it. [1] is a useful link.

I hope that this gave you some useful information.

/Ove

[1] http://www.cqblueprints.com/tipsandtricks/cache-flush-service.html

View solution in original post

Ove_Lindström · 10/15/15

Hi Juan,

without knowing more about your project, I first have to ask a couple of questions.

First, if you are close to a "go live" in the production environment, in what kind of environment have you been developing and testing your application to this point?

My opinion is that you should always try to develop, deploy and test as production like as possible. If you need an application server for any reason in the production environment, then your development, system test and acceptance test environment should be setup in the same way. There is a huge risk of getting into trouble otherwise.

Second, to try to "answer" your question, do you need any other functionality that requires an application server in order to deliver your solution?

I have come across some functionality from other third party vendors that configures and integrates nicely in an application server environment but does not have a nice OSGi enabled binary. Then we would have to do quite a lot of "magic" to make it work and get limited support. If you don't have anything like that, less is always more. Go for the standalone version. You can always migrate your repository later.

To your CDN question. As far as I know, there are no OOTB Akamai to CQ integration. It is standard CDN work here. Some things that you should have in mind is what parts of the site that is long term and what is short term. You would like to be able to purge everything under /etc/design/ separately so that you can clear out all cached css and client library file from the CDN when you do a new deployment. More static files, such as /content/dam is not something you would clear every time you release something.

Then you need to take in consideration how you should handle re-activation of already cached URL:s. Is it enough that a new page appears in the CDN after the stipulated time to live (TTL) or do we need to send a purge message. All CDNs I have worked with have this kind of purge API that can be used, but you have to figure out what would trigger it. [1] is a useful link.

I hope that this gave you some useful information.

/Ove

[1] http://www.cqblueprints.com/tipsandtricks/cache-flush-service.html