Software Architect 2015: Day 1
Day 1 of the conference sessions of this year’s Software Architect
conference is over, and here’s a few brief notes from the sessions I
Microservices: the Good, the Bad, and the Ugly
By Sander Hoogendoorn
Microservices have been a key topic of conversation within the software
architectural community for the last two years, so it naturally follows that
both keynotes on this opening day were based around the topic.
Sander kicked things off discussing his experiences with building
microservice-based architectures, covering both the benefits and the costs and
tradeoffs that have to be considered along the way.
He highlighted that microservices as a concept is somewhere on the “peak of
inflated expectations” point of the Gartner Hype Cycle, with lots of
both proponents and a reasonable number of (vocal) detractors, but the truth of
the matter, as usual, lies somewhere in the middle.
An important takeaway from his talk was that he considers a non-evolutionary
microservice design (i.e. one which hasn’t evolved from an existing system, so
you can understand where the system boundaries should be) to be a mistake. He
expertly illustrated this point with the help of Finding Nemo:
By Simon Brown
I attended one of Simon’s “Architecture for Developers” workshops a couple of
years ago, and found him to be an engaging teacher, so I was looking forward to
his talk here.
As a counterpoint to Sander’s talk, Simon began by asking the following simple
If you can’t build a modular monolith, what makes you think microservices is
There are plenty of benefits to a microsevice-based system architecture, but it
is not a silver bullet. Many of the decisions that go in to creating a
successful series of microservices are the same as those for a successful
monolithic architecture: primarily that of finding the right modular approach
to splitting up the application.
Monolithic systems are often described as “big balls of mud.” If you expect to
take one of these mud balls and simply create a series of microservices, then
you’ll likely just end up with the same problems but with a network on the way:
a distributed big ball of mud.
Design by Coding: Extending the Principles of TDD to Architecture
By Allen Holub
In this session, Allen introduced his “Design by Coding” practice, in which he
takes the principles of TDD (tight cycles of red-green-refactor) and applies
them a level up to develop a domain-based architecture incrementally. He does
this by effectively taking a user story and building up the public API for the
component being created bit by bit, ending up with a framework of code, with
associated unit tests, that can then be implemented using a more traditional
Unfortunately, I’d watched his 10-minute video on the subject which was
linked from the (agenda on the conference website) before the conference, and I
found there was little additional context added which, given the 90-minute
session slot, was disappointing.
He also spent a fair amount of time Scrum-bashing (“Scrum is not agile; if
you’re doing Scrum you’re not agile”) and talking in ideals (assuming the
customer is always going to be sitting with you, for example), which I found
detracted from the core content of this session.
Design Visualisation: Smoke and Mirrors
By Ruth Malan
Visualisations are a key mechanism for expressing the intent of the design for
a system. There’s often a distinct gap between the original design and the
final system design as built, and the core concept of Ruth’s talk centered
around the cyclical process of deciding on the intent of your design, coding
that design, then reflecting on what was implemented and surfacing the
differences from the original intent, before repeating the process.
I was hoping for some concrete takeaways from this session in terms of
practical visualisation techniques that could be applied to my own projects, but
unfortunately I found the whole talk to be lacking in structure and content.
It seemed to take nearly the first hour of the 90-minute slot to get to the
crux of the topic, but even then concepts were brushed over in a very haphazard
manner, and never fully explained.
Continuous Delivery for Architects (Neal Ford)
By Neal Ford
In the final session of the day, Neal discussed six key changes in approach to
architecture and engineering practices that applying continuously delivery
- Yesterday’s best practice is tomorrow’s antipattern. Architecture is abstract until put into operation, and nothing is static. Even if you don’t touch a system for a year or two, the ground on which it is built (infrastructure, best practices and so on) have changed, and you need to be able to deal with this situation.
- Expanding role of architect. With the advent of continuous delivery, the role of the architect has expanded to involve not just the creation of the software, but also the full lifecycle of development, deployment and maintenance, as well as becoming a conduit for communication between previously disparate teams such as operations and DBAs.
- Understanding shifting structure. Architects no longer have the luxury of months of up-front planning. Agile approaches to software development mean that a lot of architecture is now performed “in-flight” as a project progresses.
- Mature engineering practices. Continuous delivery necessitates the automation of much that was one manually performed, not just testing and building software artefacts, but also the creation of immutable, code-driven environments within that software runs. In addition, the pace of CD requires solid control over things like monitoring and logging, as well as release strategies like feature flags and canary builds.
- Manage coupling intelligently. The use of sensibly structured libraries (compile-time dependencies) and services (run-time dependencies, likely remote services), and well as the challenges that a distributed architecture brings (e.g. contracts and versioning, responsiveness and availability, authentication and authorisation, centralised logging, and atomic transactions) and a move much more towards domain-driven design, specifically around the concept of bounded contexts.
- Move towards evolutionary architecture. In CD, components are deployed; features are released. Evolutionary architectures provide the flexibility to perform easy experiments, trying ideas which may work, or may pivot or be discarded completely, but the cost of each experiment is low. Individual services and small behaviours may change gradually, and older systems are removed as necessary, automatically if possible.