Last week I was fortunate enough to attend the BuildStuff 2016 conference in Vilnius, Lithuania. Hosted at the Radisson Blu Lietuva hotel, there was plenty of space to accommodate the sprawl of a conference and everything was well-organised. Most importantly, they were able to deliver coffee like we can all only hope to deliver software – with high-quality and constantly.

My personal goals from this conference were two-fold. Firstly, exposure to ideas perhaps a little outside the ‘norm’ in terms of how Tombola currently operates and secondly to hear from people’s actual experiences of living with various platforms or tools.

The Old New Things

oldnewthingsThe overarching theme was “The Old New Things” with some talks reflecting this more than others and I’ll try to summarise my own personal highlights here.

Greg Young opened the conference with his talk “The Long Sad History of MicroServices”. Microservices is one of those words that seems to invoke semantic satiation in me – the phenomenon where repetition causes a word to lose all meaning. Peeling back the buzzwords for a moment, Greg reveals that a lot of these ‘new’ concepts are far from it. By challenging our desire to use the latest shiny ideas, Greg urges us to take a step back and ask ourselves what problem we are trying to solve and see if we are re-treading old ground. (Spoiler: we almost always are)

There is no industry consensus yet regarding the properties of microservices, and an official definition is missing as well. (Wikipedia)

Personally, I am struggling to get behind the push to microservices for all because I don’t think everyone needs them and it might be prudent for us to look before we leap on this one. To paraphrase a little from the conference, “if you don’t like your monolith, spitting it into smaller monoliths wired up with network cable won’t make it any more likeable”.clippy

In a later talk, Dan North challenged the audience to consider their staunchly held beliefs on various concepts. Write tests first or later? Automate builds or do them manually? Tabs or spaces? Well you probably think you know the answer to all of those questions as I do but the truth is there are almost always justifications for going against the received wisdom. It seems prudent to always examine why you apply a certain best-practise and whether it is best for you – and this push to microservices seems no different.

DevOps in The Real World

Two talks that really caught my eye were from Michal Ostruszka’s “Don’t Fear The Devops” and James Nugent‘s “Building Self-assembling, Self-healing Systems in the AWS Cloud”. Both focus on two similar techniques for managing any kind of infrastructure and deployments onto it.

Michal demonstrated how he had been living with Ansible, an open-source platform for automating configuration-management, application deployment and many other things. Ansible allows you to control all your infrastructure without needing to have agent software installed on remote servers and the focus is on ease of use. All you need to do is provide Ansible with a description of how you want the configuration to be for your infrastructure, it looks at your current set-up and derives which steps you need to take to apply in order to get your required state and then can run them for you.

James Nugent used Terraform to demonstrate a similar concept and on the face of it both Ansible and Terraform are very similar but Terraform seems to be more aimed at the use case where rather than upgrade services in-place, you would bring up new infrastructure to replace those services which seems to fit into the ‘servers as cattle rather than pets’ paradigm. Personally, I like the idea of immutable servers that are thrown away during upgrades and deployments and it has extra benefits when considering disaster recovery and removing tight coupling to one cloud vendor.

I’m definitely going to spend some of my personal development time to investigate Ansible and Terraform further. How cool would it be to build our configuration files up in our sandbox environment and once they are ready for deployment to stage/production – this file would provide our infrastructure team with a complete list of deployment steps which can be deployed automatically after review? Rollback plan? Just checkout yesterday’s configuration files from git and let the software work it all out for you…

Just one more thing…

Before I sign off, I feel I need to make a special mention of Dan Shappir, a performance specialist from His talk was entitled “Make it Faster!”. Now who doesn’t want to make their code faster? Absolutely fascinating stuff from Dan who demonstrated that in the pursuit of speed, there is always something else you can do to squeeze out more performance. It was fascinating to see how Wix have been able to monitor performance beyond page delivery times and right up to and including the time taken to set up Javascript libraries inside the client – something espoused by Google’s RAIL model.

Anyway, that’s enough from me – a great few days, a little inspiration and a lot to think about over the coming months.