Alex Hudson

Thoughts on Technology, Product, & Strategy

Responses to “Software architecture is failing”

It has been just over a week since I wrote that software architecture is failing, which received a level of response I didn’t expect. The reason I wrote the post in the first place was to set the scene for some future posts I want to write: as I said, I don’t think we talk enough about architecture for SMEs particularly, and I want to spend some time focussing on those. This post described the reason why.

However, one thing was very clear: the post overall, and many of the ideas within it, strongly resonate with a much larger group of people than I expected. I want to reflect on that a little, but first, let’s look at some stats.

Read More

Faster Continuous Integration with some stowage patterns

Everyone wants faster Continuous Integration (CI). The quicker you can get from commit to test results, the better – but there’s a bit of tension here. A CI should start close to “first principles”, so that you know an entire build is good and repeatable. But the more work the CI is doing, the slower it will go.

I’ve mentioned before that I use a combination of stowage and container-based CI systems, and in professional life we’re very heavily invested in GitLab now (which is an excellent system in general). Containers are a good starting point for CI, because they’re very easy to set up, do some work, and then throw away again. Getting clean builds is very straightforward.

Today I released version 0.5.0 of stowage, which brings a few additional small features which really simplifies usage in CI.

Read More

WPA2: Broken with KRACK. What now?

On social media right now, strong rumours are spreading that the WPA2 encryption scheme has been broken in a fundamental way. What this means: the security built into WiFi is likely ineffective, and we should not assume it provides any security.

The current name I’m seeing for this is “KRACK”: Key Reinstallation AttaCK. If this is true, it means third parties will be able to eavesdrop on your network traffic: what should be a private conversation could be listened in to.

This has happened before with WiFi: who remembers WEP passwords? However, what is different this time around: there is no obvious, easy, replacement ready and waiting. This is suddenly a very big deal.

Read More

Software architecture is failing

I doubt there has ever been a time when software architecture was seen as a raging success. The “three-tier architecture” of the web has held up extremely well and is an excellent place for many people to start. The “12 Factor App” approach has encouraged developers to adopt practices that make deployment and scaling much simpler. Over the last couple of years, though, I’ve noticed developers advocating for architectures I consider to be extreme and limited in utility, foisting highly complex systems into startup environments at great cost. It appears to me to be getting worse.

Read More

Improving the metaphor of technical debt

RedMonk published a great article today on the incompleteness of technical debt as a metaphor. This touches on a number of points, the best one I think is that for many people in business, debt just isn’t a “bad per se” thing. Technical debt, more often than not, is.

I completely agree with the analysis. Presenting technical debt as risk is a more accurate picture a lot of the time. While it’s potentially even more accurate to relate them to other financial instruments (my favourite is the “uncollateralized technical debt obligation”), it’s much more difficult to relate to.

I’d like to share the simile I use.

Read More

Pokémon Architecture

Millions of words are expended on software architecture. Fashions come and go; some patterns last a long time, others are a flash in the pan. One day, Model-View-Controller is all the rage. The next, it’s Model-View-ViewModel. So on and so forth – the next new architecture is the One True Way or a genuine silver bullet, until it’s not, at which point it’s legacy, technical debt or code smell.

Developers talk too much about architecture. In the future tense, it’s always what the next architecture is going to enable them to do, what problems it will solve. In the past tense, it’s usually about what the architecture prevents them doing, why the architect was bad, why it’s the wrong pattern, etc. Static architecture design is the wrong thing to think about, and here’s why.

Read More

A defining time in deployment: thoughts on Istio

Last week I gave a lightning talk, ostensibly on Kubernetes / docker / prometheus, to a motley crew of London CTOs. I rarely give talks these days, so of course I ran over massively. There’s so much I’ve learned, and my teams have learned, attempting to force a discussion like this into a lightning format feels trite (in retrospect).

There’s a key reason for this. In my talk, I called it the “Cambrian explosion period of Ops”: there are a multitude of tools available, more are being developed all the time, and there’s a huge amount of overlap.

I don’t want to try to predict when we’re going to hit “peak Ops tools”. Serverless is a way off from hitting most mainstream teams yet; it’s still a novelty right now, will grow very quickly around 2020 and will probably be dominant by 2025. So, we can’t be that far off the peak – and another sign of this is that we’re beginning to see real consolidation.

Read More

Initial impressions on Symfony 3.3

I wrote a couple of times previously about Symfony 4, particularly the architecture and use of Makefiles. It’s now at the point of being testable, so I took it for a short spin.

One comment for Linux users: your operating system will probably need an upgrade. I’m a Fedora user, and the stable release only includes PHP 7.0. Although that’s recent, it’s not good enough. Thankfully Fedora 26 has been in alpha a little while, and the beta is due at the end of this month. It was an easy upgrade, and includes PHP 7.1.4, a new enough version.

Read More

Articulating the ATOM approach

It’s interesting watching history repeat itself. There are a number of fashions that come and go in technology: thin client computing comes back every twenty years or so, for example. In the 80s, Unix was very big – it faded a bit in the nineties but then came roaring back with Linux.

Another venerable bit of software is coming back into fashion – good old Make. It’s not the perfect tool by any means, and the niche it once had is no longer that relevant. However, I think we’re going to see a growth in its usage once again. Let me explain why.

Read More

Lean versus Agile

People sometimes ask me about the structure of our internal development team, and to what extent we’re truly “agile”. My response is that we’re actually more “lean”. I happily give examples of some of the key working practices we have. I generally don’t explain the difference between “lean” and “agile”, though.

Sometimes, people use these terms interchangeably. I think this is wrong, but understandable. As a JIRA user, I’m used to it offering a Kanban board to run a scrum sprint. This can be a great choice, but it muddies the waters. Let me take this opportunity to explain my thinking then!

Read More

Page 1 of 18