Cloud Deployments

The next Sitefinity release - 8.2 will include improvements in the support for cloud deployments.

We will be focused on Windows Azure and Amazon. We're going to provide support for Windows Azure Websites and Amazon EC2. Those installations will use Redis (available on both Windows Azure and Amazon) for NLB communication.

We'd like to hear from you!

What were the major pain points/missing features you encountered with those environments and what do you expect from Sitefinity?

We will appreciate your feedback.

Thanks,
Best Regards,

One pain point would be Azure's December 2015 planned removal of Microsoft.WindowsAzure.StorageClient 1.7, which is still present in SF 8.1.

Is an upgrade to the storage API anticipated for SF 8.2? (Really, a hotfix release would be even better)

Unless we've misunderstood something, azure deployments end up being too expensive due to the cost of azure search.  Do you have plans to enable a lucene based search that stores things in blobs?

One issue that I often notice in Azure is a dependency dll, msshrtmi.dll. It is a dependency of the Azure dll's in the project. Often there is a clash between whats installed on the azure instance and what the SF versions want. Me I always include the correct version in the project so I avoid the error.

One issue I have found is the Azure dlls included in the project require a specific version of the msshrtmi.dll. Else the web fails with a "dependant dll is missing" error. To fix the problem I include the correct version in my project and deploy it with the rest of the files in the bin directory.

The main reason lucence search does not work is because of file permissions.

If you change the folder permissions of the search folder to read\write then the local lucene search works. It will also work as you scale an Azure App as the the file system is shared across all instances.

To change the file permissions on a deployment you can add a .target file to your project which can set it. (From VS I use web deploy and the target file to achieve this)

I think it would be nice that this option is made easier to achieve.

As Betty mentions. On Azure you have 50MB for free or 25GB at $250. (Ideally Azure would offer some better step pricing on this one)

@Darrin, good to know! Last I had checked the indexer actually had code to detect azure and disabled it completely, that was probably back in 6.3/7 though

I would really like to be able to move my SF Cache from In Memory to Redis.

Currently SF stores its cache in memory. If you scale out you end up storing the same copy of cached files on every server. (A big reason for the need to have each web server talking to the others so as to clear and update local caches)

This can lead to scaling out not solving your problems when memory is an issue. You have to scale up.

Ideally we could move the cache to Redis and potentially not even need each node to communicate to each other?

I raised a bug that the new Azure SQL (v14 ??) does not work with the current Thunder when deploying the SF database.

An initial deploy to Azure websites is (was) easy when it did work. Select to deploy to the cloud (select just the database option) and up it went.

Another issue is that Thunder does not like it when the connection string is moved to the web.config file.

I think the connection string is better in the web config file because it then allows you to change the connection string with web transforms as part of your publish profile. (Yes there is the option to use slow cheetah)

Also when deploying to the Azure cloud you often need to ensure that you do not deploy your local configuration folder. Within thunder it would be good that you could do a deploy and it give you deploy options such as exclude that folder. Along with considerations for file based image storage or the Search folder if using Lucene (And you have enabled write access as mentioned in the suggestion above)

The ability for thunder to deploy to Azure Websites. Check and compare configurations between local and cloud. Nice confirmation screen about what and how it will deploy. Deploying to Azure staging environments.

And get Thunder working in VS 2015 which has great Azure integration features. Stop me having to flick back to VS 2013. Very annoying!!!!

Hi all,

Thank you for sharing your suggestions. Let me try to answer some of your questions.

@Nicholas: we are planning to fix the old storage API references with the Sitefinity 8.2 release

@Darrin: I cannot commit about Thunder at the moment. However this does not mean that we will not provide some sort of automation with Azure App Service. We will publish Azure Resource Manager templates which will allow you to automate the provisioning and deployments within App Service.

 @betty: There is another alternative to using Azure Search when you are running in the cloud. If you want to use the regular Lucene you would also have to use some common storage (local files are not an option). Because of this we are also supporting using ElasticSearch for handling indexing and search. What you can do is create an ElasticSearch server in Azure (you can even use Linux VMs for this)  and offload the search feature to ElasticSearch.

@Radoslav, yeah I know ElasticSearch is another option, and while a server can cost less than $15 a month in Azure Costs you then have to consider maintenance and patching costs on top of that.

 There's libraries out there for Lucene that allow the use of blob storage which is persistent and can use local file system for temp for speed.   I could write my own search provider to do this, although I suspect the ilmerged lucene could cause some issues.  This option should be significantly cheaper than both Azure Search and Elastic Search. azuredirectory.codeplex.com/

Thank you for the clarification. This is something that we can definitely build upon, unfortunately we cannot commit to handling it with the 8.2 release. Nevertheless the cloud support feature has a lot of things like this one and moving from in memory to distributed cache to be developed. I will keep you updated when we plan any of those.

I guess my biggest question is why do you need NLBl. Also, if you aren't doing any local persistence, why do you need include the Azure sdks. I mean after all it is an APS.NET  web app that you want to scale. Maybe I am missing something on why all of these dependencies need to be there.

My best case scenario would be:

1. Create the Sitefinity application

2. Change the connections strings

3. Web deploy to Azure using the tools that are part of Visual Studio.