How Seek and Everydayhero put Docker into production

Docker’s meteoric rise in popularising application container technology has not gone unnoticed in Australia, with companies including Seek and Everydayhero pioneering local adoption efforts.

Speaking at the recent Australian Cloud and Data Centre Summit co-organised by iTnews, Seek and Everydayhero joined Craig McLuckie, the co-founder of Google’s Kubernetes orchestration tool for Docker, to outline their experiences with early Docker adoption.

“I’ve never seen a technology reach the rate of acceleration of Docker,” McLuckie said.

“I’ve been in this game for 17 years and this is by far the fastest, most aggressive adoption cycle I’ve ever seen.”

Docker provides a lightweight way to package and ship a Linux application or service.

These packages – called containers – can easily be moved between environments, such as between clouds or virtual machines, and can be started up in seconds.

The first version of Docker was released in March 2013, and within 15 months it had been downloaded 2.75 million times. That figure jumped to 21 million downloads just four months later (coinciding with version 1.0’s release), and is now over two billion.

This is one of the key reasons Docker is so hyped: as Insight Venture Partners managing director Jeff Horing told Forbes, it’s a business tool that “looks like it has a consumer-like adoption rate.”

However, McLuckie noted there was still a “big gap” between the rate of interest and adoption.

“There’s a big [difference] between finding it and playing with it, and getting a really successful production,” he said.

“The technology itself is pretty nascent. There’s a lot of rough edges.”

The rough edges are well-known to early movers like Everydayhero’s lead software engineer of platforms Marty Zalega, though he argues they are becoming less of a barrier to adoption.

Brisbane-headquartered Everydayhero is a hosted fundraising platform that can be used by individuals and charities.

“The major pitfalls we experienced were jumping in early,” Zalega said.

“There was a lot of development by Docker that really affected us. It was great that it was developing very rapidly and helped resolve a lot of those teething issues, but at that point we were also learning so we had to keep trying to catch up and rediscover how Docker worked.

“Right now if you were just jumping into Docker it’s definitely not something that you’re going to be faced with.

“It’s getting very stable, the toolset’s very rich, and the processes around it are much more refined.”

McLuckie agreed that the community was maturing. Docker has built its own sizable user community that offers crowdsourced support, and Docker meet-ups now occur in many capital cities.

“The thing I would say is distinct and relatively unique about Docker and a lot of these new technologies is the quality and level of support you get from the community itself,” McLuckie said.

“When you engage the Docker community and other new open source communities it’s an open and very effective way of understanding what’s coming and working through issues. There’s a very strong internal kind of support structure.”

Seek Australia principal developer Martin Booth argued the benefits of moving to Docker far outweighed any perceived concerns.

“I think the consistency Docker brings to software deployment counteracts the learning curve to use it,” Booth said.

How Seek got started on Docker

Seek first started experimenting with Docker in its Australian operations, initially in support of a microservices architecture which requires applications to be designed as a series of independently deployable processes or services.

“We were finding it was taking quite a long time for people to start a brand new service,” Booth said.

“There were a lot of overheads in building and getting one out the door, so I was tasked with looking at how we could automate the creation of a new service.

“That got us looking at the best tools to do that.”

Seek tried several different methods of deploying new services.

“One was a typical one where we zip everything up, move it across to the destination server and extract it,” Booth said.

“But we had issues where the code wasn’t tied to a particular version of the libraries that it needed, so if we deployed a version of the code that required new libraries we’d then also have to have an out of band method to update the server with those libraries.”

Booth said the company tried to solve that by packaging everything in virtual machines, but the VMs were “slow to create and deploy”.

“Docker seemed to be the answer – a midway point between both of these two problems,” Booth said.

Using Docker templates, a new service can now be put into production in about 20 minutes, he said.

Though Docker use started for Seek in Australia, the international nature of the company’s business means the tool’s use is being expanded.

“We are currently looking at using containers as a means to share components between the international businesses,” Booth said.

“Not all of them use the same cloud provider as Australia so for us it’s about application portability.

“We have components that we can put onto an internal Docker registry and share between the various different business units.”

Code of choice

Software development teams at Seek presently code in their language of choice.

Prior to Docker, components or services coded in different languages were deployed differently, but with Docker, code deployment methods are now consistent and standardised.

However, there is still complexity – and Seek’s developers are already having tough conversations on whether to drop some languages entirely in order to smooth the path to Docker.

“We use some C# and some F# code in our environment. Both are the most difficult to use with Docker,” Booth said.

“It’s not a problem with Docker itself."

As a workaround, Seek uses an open source implementation of the .NET framework called Mono, which enables developers to code in C# and F# for Mac and Linux.

Seek uses Mono to continue coding in Microsoft programming languages, while deploying the code using Linux-based containers.

But Booth noted that Mono may not be a long-term solution.

“Serious discussions have happened in Seek about whether or not we really want to persist with F# because we find the Docker situation so compelling that most teams are actually willing to give up their language of choice to use Docker,” he said.

“We’ve had some success with some of our applications running perfectly inside a Docker container.

“We’ve had other problems with it which have always been traced back to an issue with Mono rather than Docker itself. Docker has worked flawlessly in every case.

“C# gets the most testing from the Mono development team. F# has had the most issues so a lot of the teams who have chosen to use F# at Seek have moved onto another functional programming language instead.”

However, it may not come to this.

Mono’s creator Xamarin was recently bought out by Microsoft, and Mono now falls under the auspices of the .NET foundation. There is hope among developers that Mono and .NET engineers will collaborate to improve the former.

Microsoft is also expected to release Docker-like containerisation functionality for Windows in the future, which could also streamline the path to containerisation for Microsoft programming language shops.

Need for speed

Everydayhero began its Docker journey in the beginning of 2015 when it shifted from running its own bare metal servers in a Sydney data centre to AWS cloud infrastructure.

“We wanted to run our applications on distributed infrastructure,” Marty Zalega said.

Zalega said the infrastructure move was used as an opportunity to examine other tools that might be used to uplift internal capability – and “Docker was the hot item at the time.”

“Docker gave us the opportunity to deploy applications very fast. We usually go from build to deploying to production and live in about five minutes,” Zalega said.

“But we got a lot of other benefits. Once we started using it, we started realising that we can use this for pretty much everything.

“Our whole workflow to this day is based on Docker. We literally build our applications inside Docker, we distribute it via Docker, and we test those artefacts in Docker.

“It gives us a good, consistent artefact that we can take from build to production in a very rapid fashion and we can have confidence in.”

Zalega said Everydayhero placed a lot of emphasis internally on rapid deployment and manoeuvrability of software artefacts.

“For us it’s a big deal because we want to get quick feedback,” he said. “We want to see things fail very quickly so we can react quickly to address them.”

The company also derived value from Docker by using it to empower developers to take ownership of delivering functional applications, and similarly sees it as a way to make a microsevices architectural approach work.

“As the world approaches microservices it becomes very hard and tedious to work with so many bits and pieces of code,” he said.

“At least with Docker you can bring them together in a coherent fashion and work with that so that, from a development point of view, you see the pieces and cogs moving and analyse and make decisions based on that visibility.”