So last Thursday (19th May) Codebase hosted the regular Docker Meetup in its new event space within the low-level entrance area at Castle Terrace that is attached to the brutalist Argyle House complex. The event space and new hot-desking area look suitably 21st century and I imagine this will prove a popular venue for all kinds of earnest entrepreneurial activity. With the surrounding roads closed to facilitate a bicyce race, there was plenty of opportunity for confusion, but nevertheless a good crowd were able find the venue and negotiate the whistle-blowing stewards to attend two very informative talks on orchestration / clustering docker platforms.

First up, Adrian Mouat gave a lightening talk on the OpenShift platform, Red Hat’s take on Google’s Kubernetes framework. Orchestration is probably the hottest topic in the docker space right now, and as far as I can tell there are three main contenders fighting it out for container domination: Docker Swarm, Kubernetes (with derivatives such as OpenShift) and Marathon.

The entry level option is Docker’s own solution called Docker Swarm, which is the only docker clustering tool I’ve experienced so far. Docker Swarm is low-level and effective, but not particularly feature-rich. Kubernetes has a slightly higher-level, more complex and – as Adrian described it – “opinionated” platform, adding features such as automated rollout and rollback, load balancing and storage orchestration. Marathon is a full blown “production grade” platform for keeping entire data centres running, which does Docker well but also manages a lot more than just supporting Docker.

OpenShift occupys a niche somewhere between Kubernetes and Marathon, providing a powerful, but relatively unintimidating way of keeping your containers stacked nicely. The main features Adrian highlighted for the OpenShift platform is a web UI for managing and viewing the state of the system, an integrated container registry and the ability to create projects that control access to resources for a particular set of users. The registry takes some of the hassle out of setting up your own private container hub, setting up certificates and other tricky configurations automatically.

One interesting feature Adrian showed us was the ability to turn any Github repository into a Docker container using the OpenShift “source-to-image” process, where the system automatically chooses a suitable image to host the code base if it can’t find a Docker file in the root of the repository. So, for example, it can detect if the code is using Python MongoDB and pick an appropriate image to launch the container, using OpenShift’s large set of applications templates.  The UI looks rather swish too; Adrian demonstrated the up-scaling of a service with a click of the very hipster +1 button. There is a free to use version of OpenShift and an enterprise version, with support bundles, which would probably make sense for those organisations that have already bought into the Red Hat ecosystem.

The next presentation was from independently-minded consultant data scientist, developer and entrepreneur Radek Ostrowski of Fast Data Ltd, who took us through the idea and implementation for his winning entry into the IBM sponsored Hackathon (Sparkathon) showcasing IBM Bluemix. Radek had a really neat idea for an app called “My Perfect Weather”, where you can specify what kind of weather you want and find out where in the world that perfect weather is happening.

Having had a go at a hackathon myself last year (without Radek’s success) I was pleased to hear it wasn’t just me who spent far less time writing the code than he did making the stupid video. Radek mentioned his last Docker meetup where he had promised that he’d give up his job at a bank and go and work from a beach.  He got a big cheer when he announced that was exactly what he’d done! And it was from afore mentioned beach that Radek built “My Perfect Weather”, so I guess it shows there’s some hope for us all.

To a certain extent there was no compelling need for “My Perfect Weather” to use the Bluemix stack – the application does not demand large amounts of cloud storage, Spark machine-learning or instant scaling of Docker containers. These were more requirement of the Hackathon than the application. Nevertheless it was useful to see how Docker, cloudstoredb and Spark notebooks come together in Bluemix. There were also problems with the demo, which according to Radek’s experience, were not entirely atypical and reflect that the Bluemix interface still has a few bugs to iron out. I guess, as with the Red Hat offering, if your company is already bought into the IBM ecosystem, it makes sense to work with Bluemix as it makes it easier to integrate various IBM services, including Watson. Another interesting assertion Radek made in passing was the interest IBM has had in Spark, grabbing almost anyone contributing to it.

Overall, I came away from the meet up feeling I’d learnt a lot. I guess Docker is becoming a compulsory ingredient in the enterprise service and support offering, and it’s interesting to see how big companies are trying to add value to the core Docker container technology stack. My guess is there is a lot more of this to come.