Cloud hosting Sitecore - Cloud development patterns

In my previous post in this series, I looked at how you can use cloud platform features to provide automated fail-over between onsite and cloud hosted Sitecore installations in the case of a disaster causing a complete site outage.  In this post I look at some of the key software design decisions that you need to consider when you are planning your cloud deployment.

Other posts in this series
Cloud hosting Sitecore - High Availability
Cloud hosting Sitecore - Scaling for peak loads
Cloud hosting Sitecore - Serving global audiences
Cloud hosting Sitecore - Disaster recovery

What about my application logic? 

In the majority of cases when we deliver Sitecore websites for our clients, the web aspect is just a part of the overall solution.  Most of the time there is complex application logic, potentially storing data provided by users and/or integration into back-end services usually fronting line of business systems that are located on hardware running inside the corporate network,  When delivering a site that makes use of the type of cloud features that we have been looking at in this blog series, we need to consider some patterns to ensure that this sort of application logic can deal with what is a different type of environment than the traditional "static" on premise infrastructure.  Let's take a look at how some of these might be handled...

Session management

Traditionally session management is one of the key issues that needs to be handled differently in a cloud environment versus simple on-premise installations.  Even when running Sitecore in a farm with more than one delivery server, I have often seen developers continuing to use in-process session management and making use of approaches like load balancer server affinity or "sticky sessions" to maintain correct behavior.  In a cloud environment this approach is not going to work, cloud services are highly ephemeral and can be summarily stopped due to everyday occurrences such as auto-scaling or upgrades.  The best approach if at all possible is to prevent the use of server side session where possible, however this is not always possible (and in some cases it is the best solution to a problem).

Happily starting in Sitecore 7.5 persistent server-side session management is becoming much more prevalent due to the inclusion of both Mongo and SQL based session state providers supporting the Session_End event required by xDB.  There is also an available Redis based session provider available which could be used to take advantage of the the Redit cache offerings from Azure or AWS, however it doesn't currently seem to properly support the Session_End event which means it likely won't work correctly with xDB without some changes.



Geographically diverse web farms and application data

The cloud based patterns that we have covered previously in this series work really well when you are publishing content published from a central management server, but in many real world cases you need to accept data or content submitted by end users interacting with your site at what could be different web farms at different areas around the world.  Although it is sometimes an option to use approaches based on merge replication in these cases, in most cases the easiest approach is to have a single central location responsible for making data updates.  Delivery servers place requests to update data into a queue and these requests are updated by central worker nodes which apply the updates, these are then replicated out to all delivery instances which display the data to users from their own local read-only store.



This different way of handling updates (commands) versus reads (queries) is an example of a pattern known as Command Query Responsibility Segregation (CQRS).  This pattern is very common in cloud application development as it allows very scalable systems, however this flexibility in terms of scaling comes at the cost of consistency.  When a user submits an update, the new value may not be available for reading immediately, and the view of data may be different based on which server you are viewing from.  However as the update is made and then replicates back through the system, it is expected that eventually the value will become consistent across all locations.  This can often have an impact in the way that you need to design the end user experience, for example making it clear to the user that the update request may take some time to become visible. When dealing with any queue based architecture, also make sure you have thought about how you are handling errors in the asynchronous queued requests that are being made, for instance look at how to handle poison messages and how to inform the user of issues.

Both Microsoft Azure and AWS include features to support these types of queue based architectures. AWS provides the Simple Queue Service  (SQS) and Azure provides a Azure and Service Bus queues.

Scaling delivery farms working non-scaling back end services

In some cases your highly scalable cloud delivery farms may need to make use of back-end services that either reside on-premise or at another location that cannot scale to the levels of your front end.   As your traffic increases and your environment scales to handle it, these back end systems could quickly become a bottleneck and become overwhelmed by the additional load.  In these cases you need to be able to throttle requests to these environments whilst reducing the impact on the overall application so that the throughput of the overall system is not constrained any more than absolutely necessary.

An architecture based on queues and worker roles is once again the standard way of throttling the load placed on back end services.  Servers in the delivery farm request all back end services by placing a message in a queue and a number of worker roles process these at a rate that will not overwhelm back end services infrastructure.  This works well in the case of data updates that can be made asynchronously and tolerate eventual consistency, however if requests need to be made to read data which the application relies (particularly if the reads are frequent) then the lag of waiting for an asynchronous process might not be tolerable.  In the case of read information, a caching service to maintain a local copy of content can maintain a high level of performance for the application whilst preventing too many service calls.  Both AWS and Azure provide managed caching services for this purpose.  Azure favours use of the Azure Redis Cache, whilst Amazon ElastiCache supports both Redis and MemCache.

Conclusion

Many times when deploying a Sitecore installation to a cloud platform your site will have bespoke business functionality built in, and you will need to ensure that this code is structured to continue to work correctly.  Persistent session management has got a lot easier as of Sitecore 7.5 and you should look to use either of the Sitecore provided Mongo or Sql Server session providers in the cloud.  You should also consider a queue based architecture for any functionality requiring data to be updated based on user input, and consider how the concept of eventual consistency impacts on the design of your user interface.

I hope you've found this series of posts of cloud hosting Sitecore useful.  Cloud hosting your Sitecore site and associated functionality provides many exciting opportunities to delivery true enterprise class capabilities for your site!

Comments

Post a Comment

Popular posts from this blog

Cloud hosting Sitecore - High Availability

Sitecore - multi-site or multi-instance?

Setting up TDS to work with Azure DevOps