Last year I enjoyed QCon London a lot, and I ended up with lots of ideas and plenty of motivation to try them out, so it wasn't a difficult decision to attend again this year. You can read all about my 2015 experiences in last year's blog post.
If you're normally sceptical of the value of computing / IT conferences, let me just say two things… firstly, based on experience, me too, and secondly, after planning which talks I wanted to go to from this year's agenda I had more than one possibility in virtually every timeslot. That's not to say that every talk I actually watched was great - some weren't - but the overall standard was very high.
This post is a summary of what I considered to be the best and/or most useful presentations that I went to, and the value I got out of them, and the overall conference experience.
The conference
I wrote quite a bit about this last year, and not a whole lot has changed. To avoid writing an essay, here are the most interesting and useful observations:
- QCon London is hosted in the QE2 Exhibition Centre, which is a great conference venue - easy to get to and fit for purpose. They certainly know how to run a conference efficiently.
- The exhibition was good again this year, with a good mix of familiar faces from last year, plus some other companies I'd not engaged with before. The CloudBees Jenkins guys had an interactive build pipeline demo and were quite interesting to talk to.
- The food was generally a good standard and attendees were certainly well looked after, although I don't understand why all hack days and conferences shy away from savoury snacks (like crisps and nuts), there was so much sugar.
- There was adequate seating for lunch, which is so much more civilised than basically every other conference I've been to. Eating standing up with one of those stupid plastic clips holding your drink to your plate is awful, and I'm glad someone has finally recognised that.
QDinner
Newly introduced and being tested out for the first time this year was the idea of providing curated meals for those who wanted to continue technical discussions into the evening (for an additional £40).
I thought this was worth a try and opted for the "Architect (Generalist)" option - meaning that I would be talking to other technical architects or similar. In order to sensibly group up the attendees, everyone had to answer a brief survey, the results of which were matched (I'm told, by hand) to other like-minded individuals.
The guys I met were cool and we did have a good chat, but don't feel like I really learned a lot - we just generally rambled about different things from our own experiences.
Overall, good conversation and good food, (it's always nice having dinner in a London hotel) but not overly valuable.
Videos
QCon staff do an excellent job of recording and editing video coverage of presentations, usually publishing within the same day. This is brilliant and offers conflicted attendees (like myself) a way to see the 2 or 3 other talks that they would otherwise miss due to attending their first choice.
Initially, access to these videos require attendees to log in to their account, but after a few months, they're opened up to the general public. As with last year, I will update this post, adding links to the presentations when they're published.
Update 02/08/2016: The videos are now public and I've added a link below each summary.
Keynote - Unevenly Distributed
Anyone that I've been to a conference with will tell you that I really don't like keynote presentations - they're usually bland and uninformative. QCon certainly does a better job at picking their keynote speakers and this year, unusually for me, I attended all of them.
I only really want to talk about one in particular - the first - by Adrian Colyer. His presentation was all about how he reads a research paper every week day and posts the summary on his blog (The Morning Paper).
The presentation introduces his key reasons for enjoying research papers:
- They sharpen your thinking skills, helping guide you to what really matters.
- You really start to raise your expectations when you see how others are pushing the boundaries and never settling for the status quo.
- Research papers provide a huge learning resource in the form of applied research - case studies showing how novel ideas have worked for industry-leading companies.
- The conversations that arise from papers building on other papers, building a context with which you can evaluate new ideas.
- Often, papers offer a glimpse into the near future of technology and where things are going, things that may be just around the corner.
The majority of the talk was spent covering specific papers of interest and linking them to the points above, but it provided a great insight into the wealth of knowledge and ideas that many of us are completely missing out on.
I would thoroughly recommend checking out Adrian's blog and his recent meta-summary of his favourite papers from the last few months.
Video link: https://www.infoq.com/presentations/research-future
Far from the mobbing crowd
A fun double-act from Matt Wynne and Steve Tooke outlining how they deal with remote working and collaboration at Cucumber (or in Matt's words "we're just going to tell you about a bunch of stuff that we do, really").
One of the key themes throughout was their commitment to mob programming, which is typically defined in the following way:
All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer.
Matt describes "mobbing" as turning "pairing" up to 11, and it's certainly something I've been advocating at work over the last year or so, but the key problem their team faces is that they're all remote workers, based on different locations (across the UK and Europe).
They go on to describe how they use Google Hangouts, Slack and Screenhero to overcome the remote-working issue while still being able to easily collaborate, screen-share and carry out the multi-player coding necessary for mob programming to work.
To make the process work they follow some simple guidelines:
- Encourage and support whoever is coding, but if you have ideas on how it could be done better, write them down and bring them up once all the tests are passing. Until then, just help them get to a state where things work.
- People can join and leave the mob as necessary (to go to the toilet, deal with customers, take phone calls, etc.) but the mob keeps going for 3-4 hours regardless.
- If the mob gets stuck, then break up the mob for an hour to do solo research / experimentation where necessary, then bring all of those ideas together as a group.
- No ideas should go into the computer unless through someone else's hands - making sure that ideas are explained and discussed instead of merely implemented.
- Have a retrospective at the end of the mob session, covering: * What did we do? * What did we learn? * What we decided * What still puzzles us?
- Retrospective write-ups are committed to the master branch, so people can read them wherever they are, whenever they want to. This keeps members of the team involved if they're off somewhere working with clients, etc.
I think these are great rules and ideas to make mob programming sessions more effective whether you're remote working or not, and I look forward to trying them out.
A fun idea that followed from the mob-doesn't-stop approach was the possibility of a 24-hour mob, with people joining and leaving from appropriate timezones. In reality that sounds fairly impractical, but an interesting idea anyway.
Video link: https://www.infoq.com/presentations/distributed-teams-remote-collaboration
Video Factory: Powering BBC iPlayer from the cloud
Stephen Godwin introduced the scope of the problem BBC iPlayer has to solve, which is delivering an astonishing amount of live and catch-up content (both TV and radio) over the Internet. Currently, the service is regularly used by 31% of the adults in the UK and supports over 1000 devices that make a total of around 10 million requests on a typical day.
However, two years ago, prior to the move towards the cloud and microservices, this wouldn't have been possible.
The bulk of Stephen's presentation was about how the architecture of BBC iPlayer was developed from monolith to microservices (and to the cloud), with a focus on the strategy and the benefits rather than the specific technologies used.
There were a few key obvious benefits from this move, such as being able to use Amazon AWS scaling capabilities at peak times, but there were a couple of specific gems that I took away:
- Almost all of their microservices are around 600 lines of Java statements (by sheer coincidence). This isn't a guide to the "right" size, but it's where their projects seem to naturally average out.
- Message queues are used within the architecture in various places, and these provide an excellent source of monitoring data - if the message queue is growing (i.e. messages are piling up) then it's a good indication that something has gone wrong. If a message stays on a queue too long, it gets shunted into what Stephen calls a Dead Letter Queue for inspection by a human / any other intervention required. Neat.
- Continuous delivery allows their developers to deploy changes to production in 15 minutes.
Elaborating on their continuous delivery strategy a bit further, Stephen dropped the following, perhaps controversial, line:
Developers should spend 60% of their time writing tests.
It's an interesting idea, and one that naturally flows if you're working in a TDD or BDD environment. Whether or not you agree with the proportion, it's clear that continuous delivery is only viable when you have a solid testing strategy based on automation.
A final point that he made about their testing strategy is that they write their acceptance tests in Ruby, even though their development is done in Java. The stated reason for this was to prevent code units being shared between the implementation and tests. I like this argument a lot and I can completely see the merit.
Overall, this was a fascinating insight into the journey taken by a development team to move from monolith to microservices, from self-hosted to the cloud, and most importantly, what this achieved for the business.
Video link: https://www.infoq.com/presentations/bbc-microservices-aws
Automating Security at Slack
I like to think I'm fairly well versed in the security of web systems. During my career so far I've witnessed UK Government approved penetration testers try to break our web applications, sometimes with success - and I've read the resultant reports, recommendations and sometimes implemented the fixes. I've spent quite a lot of time actively working with security researchers to make our applications more secure.
However, that said, I've never been that involved in securing the overall infrastructure, although I sit right next to the guys that are doing that kind of thing, so I knew a little. Ryan Huber's talk filled in a lot of the blanks for me.
The opening question from Ryan - How does a company know when it has been hacked? He discusses the best case scenario (monitoring picking it up) to the worst case scenario (you don't know at all).
Throughout the talk, Ryan describes the tools that they use at Slack to actively monitor their systems for data breaches, including rsyslog with RELP, StreamStash, and ElasticSearch.
The main takeaway for me was that centralised log aggregation and analysis is really the only way to take infrastructure security seriously, and the only way you're going to detect a breach if or when one happens. Keeping your detection rules (i.e. what you're actively looking for) a secret is also key to preventing anyone from exploiting weaknesses in your alerting.
If you're working in a team practising DevOps or you're part of an ops or sysadmin team somewhere, you should learn more about the ELK stack and other tools that can assist you in automated detection of security breaches (or concerning activity in general).
I thought this was a very useful talk with a lot of practical, sensible solutions for breach monitoring.
Video link: https://www.infoq.com/presentations/security-slack
Engineering You
Martin Thompson is well known for his brilliant blog Mechanical Sympathy, and his presentations where he gets into incredible low-level detail about projects he's worked on, and the intricacies of the JVM. This time, he went outside of that undoubted comfort zone and talked about more of the soft skills that improve the overall ability of individuals as software engineers.
He starts by looking back to a report from the very first software engineering conference in 1968, which is full of interesting discussions about concepts that are very relevant today. I won't quote from the report, it's well worth a read in its own right (if a tad lengthy). The point being made was that we're still learning lessons that some of these earlier software engineering pioneers had already figured out!
His advice, although fairly wide-ranging across a lot of core computer science/engineering topics, is generally to focus on learning and improving knowledge (and application) of the core fundamentals; things like algorithms and data structures, different paradigms, etc.
What I liked particularly about his talk was that he proposed some simple ideas to bring these fundamentals into your day-to-day work, such as when writing tests for object oriented code, use a functional approach so you're thinking in a different way about the problem using a completely different paradigm.
Martin also recapped some of the things that a lot of other presenters were saying (which are mostly common sense) - we can learn from working with others, from research papers, reading code, and of course, online resources.
I generally found myself agreeing with everything he had to say, and he more or less reinforced my personal feelings on what's really important; computing fundamentals, paradigms, abstraction, understanding customer needs and the ability to communicate.
This was the second highest rated talk at QCon this year, and I can see why!
Video link: https://www.infoq.com/presentations/engineer-practices-techniques
Microservice Anti-patterns
Tammer Saleh gave one of the best presentations I've seen on microservices to date, all about why you should (or shouldn't) use microservices as an architectural choice and the common pitfalls of implementing the design.
The bulk of his talk involves introducing common problems, one by one, and then outlining reasonable solutions that make perfect sense.
For me, one of the most interesting problems was how to debug microservices (or any distributed system), specifically how you tie together the reams of log entries from the various different services to form a cohesive view of how a single high-level request was handled (or not handled).
Assuming that you have centralised logging (via Logstash or similar) then he proposes using "Correlation IDs" - essentially tagging the initial endpoint request with an ID, and propagating that all the way through any service call at a lower level. This gives you an easy grouping mechanism, at the expense of a bunch of faffing around to implement it, but seems like the only real way to get sensible logs.
The other interesting problem was how to test (or develop) services in isolation - i.e. where mock services come in.
His proposal was something I'd not considered before. Rather than having each consuming service or application deal directly with other services (via raw HTTP / REST), Tammer suggests building a small client library that handles the communications; this can then be shared by lots of other consumers and can easily be switched into "mock mode" for testing purposes. It's a neat idea and I can see a lot of value without really much cost.
An added benefit is that it makes it easier to change the communications channel, for example, if you wanted to switch to asynchronous calls, or introduce a message queue, you only have to update the library to update the consumers.
The main downside of using a library to consume another service is that it locks you into a particular language (or requires that the library ported for each target language), but this seems like a manageable problem given that you would assume most sensible companies have standardised around a limited set of programming languages.
Overall, I thought this presentation was well thought out and contained loads of great ideas for solving real problems. Finally - a talk about microservices where I actually learned something useful!
Video link: https://www.infoq.com/presentations/cloud-anti-patterns
What I took away from QCon 2016
This year it was obvious that unlike in previous years, microservices are now being used in production in a wide variety of situations, and are becoming a much more mainstream design pattern, and discussion about this way of working has moved from the theoretical benefits to the pros and cons actually encountered. This is great, because now we can learn from the experience of development teams that have done down this route and avoid some of their mistakes.
Another thing that was clear from QCon 2016 is that there is an increasing focus on culture within development teams, and also the wider company culture. I'm sure it's no coincidence that this is becoming a hotter topic as microservices become more popular. To successfully implement microservices necessitates some of the current industry "best practise" behaviours, like TDD, BDD, continuous delivery and infrastructure as code, and these behaviours are all built around communication and teamwork.
In conclusion, I really enjoyed the conference again this year and got a lot out of it. I hope to go again next year!