Now that cloud is on the uptake with almost every organization, it’s likely that during the next upgrade or new implementation of SDL Web you will be asked to move it to a cloud provider like AWS. What you should not do during this move is fall into the trap of just porting some virtual machines to the cloud and running it like you did before. The cloud is better than that (and it is 2016, not 2005), so you should investigate a little deeper in how you should deploy. So to help, here are 10 things to consider;
1. Use SDL Web 8
It should go without saying that you should use the latest version of a product, but some organizations pull back from such steps until a product version is in a SP1. But with the new product release you get better support for the cloud from SDL. You can read my earlier post on the new infrastructure features that help deployment on the cloud but the main one you need to shoot for is the support for database-as-a-service from AWS or Azure
2. Elastically scale delivery
In this nice article, the AWS Startup folks at Medium explain that the minimum viable product must scale in order to be a success; they are spot on. As your product is that website you are building then not implementing automatic scaling (or using something like AWS Elastic Beanstalk) of delivery should now be counted as a crime against humanity.
3. Automate the deployment of your environment
Automating the deployment of an environment is more than saving a VM template of your build servers, but automating the configuration management, topology, software installations etc. This is essential in auto-scaling but deeply important when you are planning things like disaster recovery. The old school methods can go if you can automatically rebuild an environment inside 30 minutes.
4. Implement Continuous Delivery and then Continuous Deployment
Rome was not build in a day and therefore you need to take this slow but most cloud providers have a CD pipeline available that integrates with the deployment options available at that cloud provider (see. Visual Studio Online or AWS Codepipeline). Get to the point where you can deploy a new version of the site (or part of it) multiple times per day in a robust way.
5. Scale Publishers when needed
Number one complaint for publishing is it is slow when deploying lots of content. Well, following point four, you should not be able to spin up more publishers when needed. This does not per say need to automatic in response to load (but it could be) but it should at least be an automated process leveraging a graceful shut down and destroy.
6. Process log files with a tool like Splunk
Now you have servers spinning up and down automatically you probably have little or no access to the running application. It is therefore important to put in automatic log file analysis to ensure that the application is running error free, you can spot failure trends and you can keep the overall health of the environment high. Applications will fail and that is OK, but you need data to proactively reduce the errors, feed into your continuous delivery pipeline and improve performance.
7. Write custom monitors for SDL Web functionality
The cloud provides you with metrics for things like CPU and memory, but there are no monitors for specific and relevant SDL Web functionality. Is the publishing queue a little too long? Fire a warning to your integrated monitoring solution that something may need to change like a new publisher spun up to help with the load.
8. Deploy new CD environments for temporary sites
You can easily spin up new delivery environment should you need to deploy a new site that will only last for a short period of time. This keeps complexity low on each site and impact to another site from the new site is impossible.
9. Adopt a microservice architecture
Architecting your application in the microservice model means that CDaaS can be utilized and sites can just feed content from that. Further splitting your application into smaller functional components which can all be scaled separately will reduce software costs, improve deployment complexity, improve resilience and improve scaling.
10. Test performance and scaling actively
Too often this is the last of the pile in regards to things to do. Automatic scaling does not remove the need to test performance, in fact, it makes it more important. In years gone by, if the site did not perform it just got slow and then probably crashed. Sadly, website visitors were used to that, but it does little for your business reputation. Now we can scale automatically, all this essentially means is that we keep adding new instances/servers until we meet demand. And what follows is a small heart attack when you read the monthly invoice.
Instead it is now more important that you need to keep your application performing well. Performance should be tested in the CD pipeline as well as on a frequent basis in production. Plenty of tools exist to support this and can help testing from different parts of the world if your site needs to respond to a global customer base.
Is number 5. Easier with web 8? In the past when looking at this license files were always the blocker
For #5, the new release gives you some graceful shutdown features for the publishing services (providing you are using the new publishing setup woth topology manager). That does mean that you do not risk killing jobs (or leaving them in limbo) if you shut down the service.
Prior to Web 8, it was only possible to kill a publisher cleanly when there was nothing in the queue which is a undefined period of time (maybe never), so this should be better in Web 8, You can still do this in releases prior to web 8 you will need to have some scripts to resubmit jobs that failed because you stopped the publisher before they were completed.