I thought it was about time I tried a new IT conference having frequented QCon and others for more years than I care to admit! So, here I am, writing from the bowels of the brutalist monstrosity that is the Hilton Metropole, in London, for this years O’Reilly Software Architecture Conference.
The keynotes were, if I’m totally honest, a little flat and quite disappointing. I didn’t really understand the format – why have more than one? Maybe when you suspect the individual material isn’t quite strong enough to stand on its own? They were perfectly acceptable presentations that would have been fine elsewhere in the program, but they didn’t have the wow factor that you have come to expect from an event of this size (and cost). We heard how streaming was the next big thing; perhaps a step-change, to rival the introduction of the RDBMS – but I think we already knew that? Nate Schutta’s talk was the exception and was very good…
Architect as a Storyteller
“Nate explains why an architect’s job is to be a storyteller. Architects are essentially the Rosetta Stone of an organisation, providing translation services (or, as some would call it, the “elevator” between the executive suite and the development floors). The challenge lies in not only crafting a compelling message but doing so for wildly disparate audiences. (The pitch you give your developers will not go over well with the executives, for instance.) While we may not want to adopt iambic pentameter anytime soon (though who knows, that might encourage more people to read our various artifacts), we must consciously think about the story we are telling.”
Here are the slides.
Visualise, document, and explore your software architecture
“The Agile Manifesto has typically been misinterpreted as “don’t write documentation.” Although contrary to the authors’ intent, this misinterpretation reflects the fact that many software teams have lost the ability to communicate what it is they are building. It’s no surprise then that these same teams often lack technical leadership, direction, and consistency. Simon Brown shares approaches and tools for visualizing, documenting, and exploring your software architecture.”
This was the stand-out talk of the day, for me at least. No where near enough time is spent on this topic, in our industry. We explored tools and techniques for improving how we document our architectures. Definitely some lessons here that can be immediately applied back in the office.
“Chances are that like most developers, you love learning and having new problems to solve but hate monotony and bureaucracy. You’ve probably put strategies in place to mitigate the things you don’t like—for instance, using an anarchic development process like Agile to reduce the amount of time spent in meetings. But have you ever thought about the way in which you approach learning and problem solving?
Philip Winder argues that modern developers are in fact researchers, even if most don’t identify themselves as such. Research-driven development is the acknowledgement that developers are researchers. To that end, Philip explores shares practical tips to make people better researchers and therefore better developers.”
This talk focussed on the parallels between University Research and Software Development – the learned lessons from managing research projects that can be shared and applied to IT. I was unconvinced, beyond the obvious and not particularly helpful observations. Not an idea that is worth exploring any further. Perhaps useful as a reminder to developers that so much of what they do is not coding, but I think most programmers are acutely and painfully aware of this already.
Don’t ask, don’t tell – privacy by design
“After years of personal data breaches and mishandled payment data, lawmakers are waking up to the importance of online privacy. Eleanor McHugh explains why, to comply with new laws, we need to put privacy at the heart of our design processes. But how do we do this when design itself is often seen as the enemy?”
One definite takeaway for most people in the room – double checking EU GDPR compliance when we get back to work! This comes into force next summer and it’s widely expected that many organisations will be unable to fully support it (and therefor risk potentially significant fines). The talk featured some interesting anecdotes but was largely preaching (and a little patronising) without providing any real practical tips.
Here are the slides.
Beyond Accidental Architecture
“In many cases, existing architectures represent an accident of circumstances—big balls of mud that grow naturally anywhere there is a lack of deliberate architectural thinking and practice. James explains why you should move beyond the accidental and introduce intentional architectural thinking to your team, outlining the benefits of deliberate software architecture, from helping newer engineers understand why certain boundaries exist to enabling senior engineers to improve their skills and more.”
Certainly an interesting subject that is close to my heart, having suffered with the consequences of accidental architectures and, in may ways, made a career out of correcting them and evolving them. There weren’t any concrete tips here though that I felt would really help – like much material on the subject; it’s easy to retrospectively point out why it happens, but far harder to actually change organisational thinking. There are very real and in some cases perfectly understandable reasons why this happens, and at least it does keep a software developer in work after all…
Here are the slides.
Superheroes and con-artists – creating better teams
“Hiring and maintaining a software team is a challenging proposition. Programmers are among the toughest craftspeople to manage and assess. To gain a fresh perspective (and relieve the boredom), Don turns to the pulp fiction of his adolescence for inspiration, explaining how he maps teams from fictional universes into the software teams he would like to build.”
This was a wonderful talk to end the day. It’s always nice to finish on something a little softer, after a day of technical presentations. This was very well presented and the material was both amusing but also interesting and genuinely useful/accurate. Plenty to learn here for the budding team lead, or for anyone forming new teams and thinking about the balance and the skills required (or more importantly, personalities).
Here are the slides.
With the notable and predictable exception of Dan North, the keynotes were a little bit of a let down again. Dan was excellent, as usual, and should probably have taken a single, extended, slot. The others were, like the previous day, adequate enough talks but without any of the genuine lightbulb moments that you expect (and need, at 9am in the morning).
The Death of Cannot Reproduce, from Michelle Brush, does warrant a mention – I think it’s always worth highlighting the inadequacy of many companies in this area and the basic attitude problem that exists w.r.t bug investigation. You see this a LOT on twitter and I’ve been frustrated by it myself on many occasions – you helpfully point out a bug to your bank, grocer, phone provider, or whomever and are met with a slew of customer service guide book answers (have you tried an alternative browser, etc). Check out this thread on Twitter where Lloyds and Google (Android Pay) blame each other for my bug report and I, the frustrated customer, am left with no solution or explanation.
How to Break the Rules?
“We invest so much in technology, so why do we seem to get so little benefit in return? We introduce new processes, tools, and methods, but when you stand back and squint, the organization still looks just the same.
Is technology overhyped and oversold, as many would have us believe, or are we doing something that means we lose out on all those promised benefits? Societies work because we follow the rules, but what if those same rules are holding us back?
The problem may be because we are failing to change our habits. Dan North introduces some uncomfortable truths from Eliyahu Goldratt, author of The Goal, a cornerstone of modern management theory, that help us recognize and challenge this behavior and unlock the true value from our technology.”
Excellent and inspiring – ideas that you can take back to your company and easily apply to bring about real, positive, change. He essentially reverse engineers a famous business book from the 80’s to produce a template (4 step process) for understanding how your proposed technology change can be successful in your organisation. The trick is in understanding what rules currently exist to manage the limitation that you are addressing and how those need to evolve to support the change you are making. From experience, it’s far harder to do than it sounds, because in a large organisation those rules are usually deeply engrained and often outside of your control to change, even if the benefits of doing so appear obvious to you.
Here are the slides.
Practical Security Principles for the Working Architect
“As our world becomes digital, the systems we build must be secure by design. The security community has developed a well-understood set of principles used to build systems that are secure (or at least securable) by design, but this topic often isn’t included in the training of software developers. And when the principles are explained, they are often shrouded in the jargon of the security engineering community, so mainstream developers struggle to understand and apply them.
Eoin Woods explains why secure design matters and introduces 10 of the most important proven principles for designing secure systems, distilled from the wisdom of the security engineering community. Eoin walks you though each principle the context of mainstream system design, rather than in the specialized language of security engineering, and demonstrates how it is applied in practice to improve security.”
As the name suggests, this was a very practical session with a useful clearly defined output that you can takeaway and apply when you get home. None of the principles were particularly revolutionary, but they were clearly explained and the condensed format is certainly useful as a high-level checklist when you set about designing a new system (or changing an existing one!). It was interesting to hear from a former UBS colleague on the challenges he faced while adopting these principles.
Here are the Top 10 principles – a useful resource to takeaway.
Here are the slides.
“Mike Roberts offers a thorough overview of serverless, covering benefits and limitations along with examples and case studies to help you understand whether serverless is a good fit for your team and needs. Along the way, Mike also discusses the key elements of serverless that will have to advance as the technology evolves.”
Nothing significant to report here!
Architecting for the Cloud
“Architects are increasingly becoming convinced that the cloud is the way to scale. The most important consideration after deciding on a cloud migration is the architectural design of the proposed infrastructure. Ann Mwangi shares considerations when deciding on and designing a cloud architecture for a business and highlights common pitfalls that teams fall into during this process.”
I discovered my new favourite buzzword. BOA – buzzword oriented architecture! Otherwise not a particularly interesting talk I’m afraid and I must confess to using the time to finish writing this blog entry – don’t you just hate those people typing away on their laptop during a conference talk!
“Drawing on concepts from his new book, Building Evolutionary Architectures, Neal investigates the family of software architectures that support evolutionary change and explains how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; Neal describes how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; Neal covers how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; Neal demonstrates how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.”
Good, but honestly I didn’t really get this – it just feels like testing to me? I think I need to revisit this, but it felt a bit like architecture ‘done right’ re-branded as something new and clever.
Thinking about thinking about architecture
“Ben explores some of the best known cognitive biases and other effects that are relevant to architectural design and related tasks, covering core patterns and anti-patterns and sharing examples and case studies from his own projects that show how more cognitive awareness could have prevented the problems encountered.
Whether or not you subscribe to the cynical viewpoint of Oscar Wilde, who said that “experience is the name everyone gives to their mistakes,” Ben helps you look with fresh eyes on your own projects past and present to understand the benefits attention to cognition can bring, in the hope of making us better architects.”
Again, nothing significant to report here I’m afraid!
Day 3 (tutorials)
Morning – API Simulation (for micro service testing)
Apart from the photographer who lacked an understanding of personal space, everyone seemed to enjoy this session. The pace was good and the content genuinely useful. We were introduced to a new tool, Hoverfly, for simulating API responses and, more interestingly, injecting faults (think Chaos Monkey). Particularly useful is the ability to run Hoverfly as a webserver, so that you can bypass the pain of constantly switching a proxy on and off on your developer workstation and continue to use your existing suite of services development/testing tools (i.e. Postman). More on how to run as a web server here. Certainly a better (and simpler) approach to the mocking of the last decade. It is powerful enough that it introduces the risk that you will no longer test adequately against real services! I’m ashamed to say I was also discovering JQ for the first time – an excellent little command line utility for interpreting JSON. All in all, a productive workshop with clear applications for the lessons learned and useful new tools that I can use for developing and testing [micro]services.
Afternoon – Kubernetes & Envoy (Cloud/Container development workflow)
A very brief re-introduction to Docker and then Kubernetes followed by a more useful and interesting deep-dive into some supporting tools and practical deployment tips. We started with Forge, which is essentially a tool for automating many of the Kubernetes deployment steps. We then covered Envoy, albeit too briefly – a next-gen proxy, designed for the Cloud, that has evolved out of NGINX and others. The idea here is to embed this proxy in our development workflow such that it can be used to provide software level resiliency. This could be through Canary Testing; enabling multiple versions of a given service, for example. This, in turn, led to another new technology – Ambassador, which, from what I can tell, is simply an abstraction of the rather low-level Envoy proxy, with some authentication features thrown in for good measure. Again, more time needed on this as home work! Prometheus was the final piece of the puzzle, providing visualisation of Envoy metrics. So, lots of new tools but not really enough time to get properly accustomed with them. It’s clear that, unsurprisingly, Kubernetes has matured over the last few years and the community and tooling have improved significantly.
Here are the slides.
Putting the material itself to one side, there were the usual complaints; far too many middle-aged men with beards, far too few women and not enough freebies – not a single free O’Reilly book, come on guys!
Overall impressions – interesting, insightful and certainly worth another visit, but perhaps it doesn’t compare favourably to the ‘big two’ incumbent London events; QCon & Devoxx.
16th & 19th October, 2017