How to look for a service provider with an agile, resilient infrastructure for your online assets. Neil McIntyre, Head of IT, Trinity Mirror

1. Trinity Mirror
Hosting Provider Selection Process
Neil McIntyre – Head of IT, Digital

2. Overview
• Need for Hosting Provider Change
• Selection Process
• Pilot web site
• Mirror.co.uk web site launch
• Where we are now
• Q& A

3. The Need for Change
• In 2009 we selected Escenic as our web CMS
• Launched first pilot site (Mirrorfootball) in August that year. The
first Escenic customer on version 5.
• Deployed on a dedicated server hosting environment.
• Following launch, the platform required continuous changes
and fine tuning.
• Dedicated server hosting limited our ability to react quickly.
• Any additional hardware required capital expenditure, purchase
orders, delivery lead time and hosting provider lead time

4. The Need for Change Cont’d
• No ability to quickly test changes and the impact.
• Failover to another data centre was a manual process and
slow.
• If we had any hardware failure that resulted in a rebuild, restore
from backup was slow and backup was generally a day old.
• Ongoing server hardware and network hardware refresh was
costly.
• We needed a more flexible hosting platform and we specifically
looked at Cloud solutions.

5. What we did
• Evaluated various cloud hosting providers in the marketplace,
including our existing provider’s solution
• Key selection criteria for us was:
• Relative maturity of solution
• Ease of provisioning
• Support for our technology stack
• Transparency of Cost
• Data Centre resilience
• Level of Support
• Scalability
• Roadmap

6. We Selected AWS
• We needed a solution before we re-launched our flagship web
site on Escenic, Mirror.co.uk, in Feb 2012.
• We actively recruited Sys Admin resource with Cloud hosting
experience.
• The Amazon self serve portal was more advanced than many
of its competitors and it met our key selection criteria.
• We decided to run an Escenic site as a pilot on Amazon
infrastructure.

7. The Amazon Pilot
• Our Sys Admin team set up an Escenic environment on
Amazon in a single zone.
• We redeveloped our celebrity web site 3am.co.uk and migrated
it to the Escenic platform.
• In October 2011 we launched on Amazon.
• Amazon web services used:
– EC2
– RDS for MySQL
– Elastic IP Addresses
– Elastic Load Balancing
– AWS Support

8. The Amazon Pilot - Result
• 3am site was launched on time with no performance issues
• Launching the small 3am.co.uk site gave us some insight into
the architecture required for our larger sites
• Following launch we created the setup in another AZ providing
data centre resilience
• Not long after that, Amazon suffered an outage in one of their
Dublin data centres
• 3am site failed over seamlessly to the second data centre. A
real time test!

9. Mirror.co.uk site launch
• Redesigned Mirror.co.uk was launched on Escenic, in Amazon,
in Feb 2012 (early morning)
• Performance issues identified soon after launch and launch was
backed out.
• Solr was identified as a major bottleneck in the architecture.
• We implemented a caching layer for Solr, adding 4 more EC2
instances
• We successfully re-launched early afternoon
• If we hadn’t moved to Amazon, it would have taken weeks to re-
launch

10. Where we are now
• Live on Amazon with 4 separate production environments
• 70 EC2 instances serving production, 15 instances in dev
• Dev environment is automatically shut down every night,
helping to control the costs
• All Newspaper branded sites will be on the Escenic platform in
Amazon by end of 2013
• Most of our acquired Digital business have migrated or will
migrate to Amazon
• Snapshot technologies for backup
• Since launch we have seamlessly (on the fly) upgraded the
MySQL database server instances

11. What we are working on now
• Recently implemented Elasticache to increase the presentation server
caches, decreasing calls to db servers
• CloudFormation
– Full copy of Production environment in 15 mins
• Hundreds of GB of data
• Large database import
• All network configuration in the same script
• Migrating our DNS to Route 53
• Auto Scaling
– Investigating the options for auto scaling platform for any peaks in traffic

12. Summary
• Hosting with AWS has many benefits for Trinity Mirror:
– Provides us with the flexibility we required
• Can create environments very quickly with CloudFormation
– Support is excellent
– Provides data centre resilience
– All our platform is supported and provisioned by a small in-house Sys
Admin team
– No more hardware refreshes
– There is a roadmap!
• There is one issue - variable costs. Requires an understanding FD!

13. Questions