Qantas Group checks into cloud for hotel bookings success

Qantas Group checks into cloud for hotel bookings success

Summary: Hooroo, an online accommodation booking company under the Qantas brand, and DiUS Computing talk about what they have achieved so far through the use of cloud computing.


The Qantas Group has seen tremendous success with its hotel bookings business after launching it in 2011, and cloud computing can take a lot of the credit for that.

In 2011, the airlines group, which consists of the Qantas and Jetstar brands, was keen on sharing in the spoils of the lucrative online hotel bookings industry. It wanted to build a hotel booking engine that would integrate with the Qantas and Jetstar websites, as well as launch its very own aggregate accommodation website

Starting out with a blank slate, the Qantas Group took a look at the technologies required to make its vision a reality quickly and at a very low price, according to Hooroo head of commercial Bruce Fair.

"There was no legacy, no systems, no website — we had a business plan we developed in conjunction with Boston Consulting Group, but that was it," he said at the AWS Summit 2013 in Sydney. "So we really had a clean sheet of paper."

But it was this clean slate start that gave Qantas Group the opportunity to pick the best offering to fit its requirements. Australian software company DiUS was to help with building and deploying its accommodation booking engine.

It was decided that the Qantas booking system will be hosted entirely in the cloud through Amazon Web Services (AWS). Engine yard, a cloud platform for Ruby of Rails and PHP, was selected as the wrapper for the entire system for control over scaling capacity, while New Relic and Airbrake will be used for monitoring.

"Because it was greenfield, there was no baggage weighing us down," DiUS Computing senior consultant Warner Godfrey said at the AWS Summit 2013. He has been working on the Qantas booking engine since the early days, and his team has been using lean software development techniques, particularly continuous deployment, to ensure that Qantas could launch an offering as soon as possible.

Three months after initiating the booking engine project, the Jetstar portion of it was launched. The airline was given a new website, with the ability to tie in its flight bookings with hotel bookings.

"Without Engine Yard and AWS, we would not have been able to release the product so quickly," Godfrey said. "Once it was in the market, we can adapt it quickly."

The Qantas website was redesigned and relaunched in June 2012, and came online the following month. In February this year, Qantas launched the ability to book international hotels. All in all, four major product releases were made in 11 months. According to Godfrey, this was something that would have traditionally required a few years to accomplish.

The booking system is continuously finetuned, and new features are tweaked and released every day, he said. DiUS' approach is also good for collecting data in real time to discover what features work and don't work, and this can dictate software development decisions.

The Qantas Group moved its assets hosted in AWS from Amazon's Singapore region down to the vendor's Sydney region two months ago. It really showed off the advantages of working in the cloud, as it only required two people and two days to prepare and actually execute the migration, according to Fair.

"After the move to Sydney, we actually found a 25 percent improvement in our page load speeds," Godfrey said. "The cloud enabled us to get the market quickly and scale."

Fair said it has been a learning curve for him to figure out the technology behind the booking platform, but he has come to appreciate the benefits of using cloud computing.

"From March 2012 to March 2013, our traffic across the three websites increased about 1400 percent, and the cost associated with our hosting only went up 20 percent," he said. "It's a great low-cost solution, and the numbers are extremely favourable to us.

"It allows us to invest in more productive areas of business."

Topics: Travel Tech, Amazon, Cloud, Australia

Spandas Lui

About Spandas Lui

Spandas forayed into tech journalism in 2009 as a fresh university graduate spurring her passion for all things tech. Based in Australia, Spandas covers enterprise and business IT.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • 4 man days to migrate..

    4 man days to move the site between AWS zones? I guess they aren't using automation and orchestration tools. Also, why on earth use PHP or Rails in this day and age?, I bet the Enterprise Architects were over the moon with that decision.
    • Clearly dont understand the complexity of these systems

      Hi Duncan, 4 days may seem long, but hotel booking engines have back end rates and inventory systems that take live updates of the number of rooms, rates, booking rules for every hotel/room in the areas they sell for. For Australia that would mean .5 - 1 Mullion live updates per week - each update being 500K-ish big. They are integrated to multiple back end systems, hotel systems, payment gateways, mail systems, campaign systems, other third party systems like trip advisor, Social platforms. So moving from one AWS zone to another in 4 days, you think is easy? How long to test that kind of move do you think? - Without Automation, How long to work with all the third party companies to ensure the integration works? I recon a 4 day move is amazing!

      As for Rails and PHP? Who uses those in this day and age - Groupon, YellowPages, Spotify, GitHub, Telstra, The Guardian News Paper - They too small for you! What would you suggest?
    • You've misread the article.

      Hi Duncan. My name's Josh. I made the decision (and the implementation) for Hooroo to deploy their very high quality Rails app on Engine Yard. It was just a consulting gig whilst I was at DiUS (hi Warner!) and I've long since moved on. Sadly, your remarks are mistaken in almost every particular.

      1. That's four effort days to prepare and execute all steps of a move between AWS regions, not between zones. For any large, established and sophisticated system with many moving parts and third-party integrations, running 24/7, and to do so with a high degree of confidence in the outcome - that is frankly superb.
      1b. Zones are not regions, they are within regions; moving between zones would be trivial.
      2. They are using automation extensively. Hooroo can, and do, push to production several times a day if necessary as the output of a CI pipeline with extensive functional and code-coverage testing. Real-time replication of all databases, content stores and indices to another region is the DR strategy. Environment provisioning is automated using Chef in particular. With these pieces in place, that is why it *only* took two elapsed days.
      3. They're not using PHP.
      4. Rails continues to be a very relevant, modern, smart and popular choice for web application programming.
      5. Your dismissive reference to "Enterprise Architects" is so very far off the mark - everyone involved in this project had a background in agile dev practices, particularly SCRUM. There was, mercifully, no TOGAF or Zachmann or other EA horrors fouling up the works on this gig.
      Josh Goodall