Lonely Planet Case Study
Lonely Planet publishes guides, mobile applications and websites for world travelers. The company also produces and develops travel and factual programming for broadcast. Started in 1973, Lonely Planet is a privately owned organization headquartered in Melbourne, Australia, with offices in China, England, India, and the US. The company has approximately 350 full-time employees and about 200 writers, editors and contributors.
We reduced the expenditure of running a shared publishing platform by 30 percent, freeing up budget for use by other parts of the business."
Online Platform Manager, Lonely Planet
The Internet, combined with the explosion in smartphones and tablets, fundamentally changed how travelers read and share information with each other. To address changes in the market, Lonely Planet decided to create and repurpose content across a range of formats, extending print to the web and mobile applications.
The company’s Melbourne development team developed a shared publishing platform to streamline the process of creating text, images, audio and video, and then uploading content to digital formats. Lonely Planet relied on 600 virtualized servers running on leased equipment in its main office to build, develop, test, stage, and launch new applications, and operated production websites out of a leased facility in Port Melbourne.
Lonely Planet had shifted to agile development and DevOps strategies to allow greater experimentation with products and services, break down organization silos, and enable a faster time to market. However, the current infrastructure couldn’t support these strategies efficiently. “Our developers were completing as few as four software builds per day, and each build took about an hour and a half to finish,” says Darragh Kennedy, Online Platform Manager, Lonely Planet. “We wanted to significantly increase the number of builds they could run on a daily basis, while cutting the time for each build to finish.”
A team based in London operated Lonely Planet’s website, lonelyplanet.com. The London office’s decision to move lonelyplanet.com from the shared infrastructure in Melbourne to Amazon Web Services (AWS) prompted the organization to review how it ran its applications.
“This decision coincided with the end of our lease with the Port Melbourne data center and the leased equipment in the headquarters data center reaching end-of-life,” says Kennedy. “We had to decide whether we wanted to invest in refreshing our hardware and extending our network contracts.”
Why Amazon Web Services
After evaluating a range of options, including Platform-as-a-Service (PaaS) solutions that ran on AWS, Lonely Planet chose AWS after a proof of concept showed that Lonely Planet’s applications would benefit from the flexibility of the AWS Cloud. “AWS was a better fit for our applications,” says Kennedy. “We believe AWS APIs are far more mature than other competitors.”
Migrating to AWS Cloud reduces latency
Lonely Planet moved its build, test, and development environments to AWS in stages. The organization began the process by dedicating a developer and a systems engineer to rebuild its application architecture. Then the IT team used Jenkins, (an open source continuous integration tool written in Java), and build agents to spin up to 70 instances automatically on AWS while maintaining the on-premises build environment. When the Asia Pacific (Sydney) Region came on-stream in late 2012, Lonely Planet moved to the new data center.
“Moving to the Sydney data center reduced latency from 250 milliseconds to 15 milliseconds, and we switched off our on-premises build environment,” says Kennedy.
Lonely Planet built out a series of virtual private networks connecting its on-premises data centers and the US East (Northern Virginia), EU (Ireland), and Asia Pacific (Sydney) Regions. After testing, the organization ran development and test copies of its publishing platform on the AWS Cloud. Once performance levels met requirements, Lonely Planet powered down its on-premises machines and migrated its entire workload to AWS.
Then the company used a similar process to migrate its production environment to AWS “We tested the environment thoroughly and went through numerous dry run migrations,” says Kennedy. “This made for a risk-free move completed during business hours by the team.”
In May 2013, seven months after starting the project, Lonely Planet completed the cutover of its production environment.
Leveraging multiple Availability Zones for high availability
The publishing platform, which runs on Phusion Passenger and Apache web servers, is made up of several applications written using the Ruby on Rails framework. The environment includes a high availability Postgres relational database operating across two Availability Zones, using a PostGIS plug-in to support geographic objects.
Lonely Planet’s environment operates 40 to 80 application servers on Amazon Elastic Compute Cloud (Amazon EC2) medium and large instances optimized by Elastic Load Balancing. The instances are in Auto Scaling Groups across multiple Availability Zones within an Amazon Virtual Private Cloud (Amazon VPC). Amazon Route 53 forwards traffic to relevant IP addresses.
Using AWS Edge Locations improves web load times
The company also migrated its India website, www.lonelyplanet.in - written in PHP and running on an NGINX proxy server - to AWS. Lonely Planet uses Amazon Relational Database Service (Amazon RDS) to operate and scale a MySQL database for the India website, and delivers web content to users using Amazon CloudFront.
Kennedy reports, “We reduced average page loading times for the India website by 50 percent using AWS Edge Locations in Chennai and Mumbai, greatly improving our customers’ experience.”
Migrating to AWS enabled Lonely Planet to avoid the cost of building new data centers and extend its agile development practices throughout the business.
“We reduced the expenditure of running a shared publishing platform by 30 percent, freeing up budget for use by other parts of the business says Kennedy. “The cost visibility is fantastic, we have capability that we didn’t have before, and we’re doing things we couldn’t do before.”
The organization has embraced DevOps tactics and developers complete a range of development and infrastructure management tasks. This has enabled Lonely Planet to consolidate budgets and increase flexibility and throughput. “We’re building infrastructure as code, meaning that we can create code in building blocks that can be checked into a repository and used in a range of environments,” says Kennedy.
Using AWS, Lonely Planet created an automated and repeatable build process that allows developers to create an end-to-end environment in a few minutes. “We can provide an environment to a developer in 15 to 20 minutes. Each developer can complete up to 30 builds a day, about 10 times the number possible in the previous environment and a sizeable productivity improvement,” reports Kennedy. “
This process has equipped Lonely Planet to launch mobile applications and websites optimized for smartphones and tablets and easily scale to meet traffic demands. “Our mobile stack sits in the US East (Northern Virginia) Region, closest to our largest customer base,” says Kennedy. “Our applications have been downloaded more than 12 million times, with demand spiking during marketing campaigns. We’re able to take advantage of the elasticity of the AWS Cloud to manage these spikes in a very effective manner. The platform’s redundancy has helped ensure the availability of critical applications — we haven’t experienced downtime since we launched on AWS.”
Lonely Planet’s experience has been so positive the company is looking into using AWS for disaster recovery support, storage and other corporate applications.
About Lonely Planet
Lonely Planet publishes guides, mobile applications and websites for world travelers. The company also produces and develops travel and factual programming for broadcast.
AWS Services Used
Secure and resizable compute capacity in the cloud. Launch applications when needed without upfront commitments.
Elastic Load Balancing
Elastic Load Balancing automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, IP addresses, and Lambda functions.
AWS Auto Scaling
AWS Auto Scaling monitors your applications and automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost.
Provision a logically isolated section of the Amazon Web Services (AWS) Cloud where you can launch AWS resources in a virtual network that you define.
Companies of all sizes across all industries are transforming their businesses every day using AWS. Contact our experts and start your own AWS Cloud journey today.