Our Essential “Developer Enablement” Tools for Software Engineers

Skyscanner Engineering
5 min readMay 8, 2018

--

By Ardy Dedase

Software engineers at Skyscanner have access to internally developed tools, services and integrated Open Source platforms that help accelerate our speed of iteration on a day-to-day basis. These tools enable our engineering teams to avoid churning hours away on boiler-plate code and instead focus their efforts on building product and features that improve the lives of our users and travelers.

Why is this important?

Skyscanner has evolved towards this position as a result of the company’s organic growth, i.e. we are currently a 900+ people organisation spread across 10 global locations that has quadrupled in size over the past 4 years (numbers are correct at the time of writing).

It’s very easy to imagine that aligning an entire company’s approach to engineering is exceptionally difficult given such a continuously changing landscape. Small decisions — like choosing a language or framework for a service, or how we test and deploy our services, or even just how we log and monitor — all become significant organisational challenges when 60+ engineering teams start making decisions in isolation of one another.

From the people perspective alone, our portability as engineers in such an eco-system starts to also depend heavily on the projects and technologies we may have used in previous teams, projects or services — and this is not a desirable situation to be in as an engineer looking to grow and evolve with the organisation.

So how have we avoided those issues?

This is where Skyscanner’s ‘Developer Enablement’ tribe comes in

We are lucky to have a dedicated tribe of engineers collectively referred to as our ‘Developer Enablement’ tribe (organised into multiple squads) who are responsible for building and maintaning the tools and services that help accelerate the speed of iteration of every Skyscanner engineer on a day-to-day basis.

This article will highlight just three of the essential Developer Enablement tools that our engineers use on a regular basis, these are the Microservices Shell (MShell), Drone and Slingshot. The Microservices Shell and Slingshot are both in-house developments while Drone is Open Source. I’m going to walk you through these three tools so I can explain why they are essential to Skyscanner engineers.

High-level workflow of MShell, Drone and Slingshot.

Reusable Components, Libraries and Frameworks

Internal name: Microservices Shell (MShell)

MShell is Skyscanner’s internal collection of standardised templates, components, libraries, language frameworks, and Docker images that helps facilitate the creation, deployment and operation of our microservices.

This collection of standardised components are packaged into cookiecutter templates that are pre-configured to work with our infrastructure. Which means all the basic configurations are already taken care of, no need to worry about the “how” of deploying my service as a Docker container on production or “how” do I make sure that my service is properly sending logs to our log streaming service.

You can imagine how this tool enables me to create a new microservice that adheres to the Twelve-Factor methodology out-of-the-box and run it in my local development environment in less than 10~ minutes.

Standardisation has improved our velocity, this was made possible with MShell.

Steps to create a new service from an MShell template.

Continuous Delivery Platform

Drone

Drone is an Open Source Continuous Delivery Platorm. It has built-in integration with GitLab which makes it a suitable continuous delivery platform for us. Code as configuration also is a big plus. Drone has a configuration file which is already pre-configured from MShell. The configuration determines the steps that needs to be done during the build process like building the Docker image, running the tests, and generating the service’s environment variable configuration.

This gives us a very flexible continuous delivery pipeline. It also comes with free integration to other useful tools like SonarQube, Snyk, and Danger.

Drone build process.

Orchestration System

Internal Name: Slingshot

After successfully running all the build steps specified in the Drone configuration file, there needs to be a way to orchestrate the deployment of those images built by Drone as Docker containers on production. Slingshot manages the deployment of these Docker containers into their target platform which could be ECS, Kubernetes or Lambda. It also provides orchestration for Blue/Green deployments to reduce service downtime and enable fast rollback if service KPIs aren’t looking healthy after deploying the new version.

Just like Drone, configuration is also declarative in Slingshot. It comes with its own configuration file with default values set by MShell when the service details like service name and owner are set. You can imagine the flexibility it provides with the configuration file, especially when you deploy those Docker containers into different platforms.

Slingshot deployment process.

Going back to the question “Why are these tools essential?”

Because once you have these three tools available, you can build other tools on top of it or around it. One real example would be a log streaming service that can be deployed using the deployment pipeline made up of Drone and Slingshot. This log streaming service will then have a client that will become part of the standard MShell template. This is a great example of how this set of tools enables engineers to build more tools to further increase their productivity.

One mantra that stuck with me after reading “The Effective Engineer” by Edmond Lau is “Invest in tooling”. I also like this quote from the book:

Effective engineers aren’t the ones trying to get more things done by working more hours. They’re the ones who get things done efficiently — and who focus their limited time on the tasks that produce the most value.

I’m fortunate to be working in a company that shares the same principles in “The Effective Engineer” and executes on them.

Like what you hear? Work with us

We do things differently at Skyscanner and we’re on the lookout for more Engineering Tribe Members across our global offices. Take a look at our Skyscanner Jobs for more vacancies.

Take a look at our Skyscanner Jobs for more vacancies.

About the author

My name is Ardy Dedase, I’m currently leading a team in the Partner Engine tribe in Singapore. We are building a platform that enables our online travel agents, airlines and affiliate partners serve our travelers better. Outside work, I enjoy travelling, playing guitar, reading and tinkering with new tech that I come across.

--

--

Skyscanner Engineering

We are the engineers at Skyscanner, the company changing how the world travels. Visit skyscanner.net to see how we walk the talk!