Launched in 2003 and headquartered in Scotland, Skyscanner is a global travel search site with more than 50 million monthly users. Their self-built technology, which includes websites like www.skyscanner.com and a mobile app, supports over 30 languages and 150 currencies. Skyscanner successfully use some highly advanced Cloud Native strategies in a mixed environment: they have a monolithic core system and a fast-growing range of supplementary microservices. Part of their estate is hosted on their own servers and part is in the cloud on AWS.
Skyscanner have now been using containers and orchestrators in production for around two years and their new code is generally “Cloud Native” i.e. microservice-based, containerised and orchestrated. The decision to move towards Cloud Native was jointly made between their operations and their development teams and their motivation was speed. The company wanted to increase their deployment frequency and velocity. “We saw the ability to move and adapt as a strategic asset”, said Stuart Davidson who runs the enterprise’s build and deployment teams. According to visionary CTO Bryan Dove (formerly of Amazon) Skyscanner’s goal is to “react at the speed of the internet”. His bold ambition is “10,000 releases every day” and they are moving rapidly towards achieving it.
According to Davidson, “Back in 2014 we were making around 100 deploys a month. We adopted continuous delivery and that helped us deploy more quickly but it didn’t solve all our problems - developers were still limited by which libraries and frameworks were supported in production. Moving to containerisation plus CD was the game-changer. It increased our deployment rate by a factor of 500”. Skyscanner’s goal was to achieve “idea to user inside an afternoon” and they have mostly achieved this. In around two years their delivery time has dropped from 6-8 weeks to a few hours. In common with many early Cloud Native adopters Skyscanner achieved this as an entirely internal project using off-the-shelf or self-built tooling.
Supporting thousands of microservices within a single environment involved defining some simplifying constraints. Skyscanner have developed a microservice shell that provides useful standard defaults on some low level operational behaviours, network interface use for example. They also specify contracts and mandate contract consistency for any new microservices. The key is that any constraints make the engineers’ lives easier but don’t limit them, “batteries are included but removable”.
For Skyscanner, the initial motivation for adopting microservices and containerisation was deployment speed. However, once they had successfully containerised they rapidly started to use an orchestrator in production to reduce their operating costs. “For us”, said Davidson, “containers were the enabler for Cloud Native”.
Skyscanner are an excellent example of evolving strategy.
- Several years ago, the team identified their first goal as increased deployment speed and their first step as continuous delivery. To achieve this they successfully developed a CD pipeline using the open source tool TeamCity.
- They identified another bottleneck as environmental limitations. Developers wanted to use the latest library versions but were limited to what was currently supported in the build system and production instances. The ops team set a goal to remove this limitation by allowing developers to bundle their chosen environment into their production deployments using containerisation. As a step in this process they moved to a more container-friendly build tool (Drone).
- Once they had successfully containerised, the Skyscanner team moved again. They decided to improve their resilience and reduce costs by using a container orchestrator in part of their production environment. They initially chose the easiest orchestrator for them to try out at the time - the newly launched Amazon Elastic Container Service (ECS). They were happy with that and it achieved the margin improvement they were looking for. As a result they have continued to extend orchestrator use in their production environment.
Having met all their goals so far, Skyscanner are now considering their next challenges, which include handling many different production environments and making microservices even smaller in order to move even faster.
Skyscanner’s voyage has been a continuous, iterative process and by no means easy. According to Davidson, “The bumps and scars make you more skeptical. Many of the tools we tried did not live up to their hype”. They had to constantly experiment and to sometimes abandon one tool entirely and move to a new one as their needs changed or the tool proved inadequate to their growing scale. They correctly didn’t view this as failure but as a valuable learning process that is only possible in the reduced-risk environment of the cloud.
However, according to Davidson, within his own team this learning came at a cost too, “every migration we had to do, every time we had to make our engineers change how they were doing something made us lose a little credibility that we knew what we were doing. As much as the engineering community in Skyscanner were awesome about this, I was always really aware of the level of change fatigue we introduced”. To make this rate of change work, several of the company’s techies took the initiative to upgrade their change management skills with a course at Edinburgh Business School.
Conceptually, the move to Cloud Native has been a positive one for Skyscanner. Their developers have embraced their new responsibilities to drive and test their own releases, ops no longer impose unnecessarily restrictive environmental constraints upon the development team and they improved their deployment speed 500-fold. However, they don’t believe their operational journey is at, or will ever reach, an end. Like their customers, their technology teams are keen to keep moving forward to new destinations.
Read more about our work in The Cloud Native Attitude.
Previous article
