Alex Hudson

Thoughts on Technology, Product, & Strategy

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

Fedora’s revised mission

Coming up with convincing vision and mission in a corporate environment is never easy – in fact, I think it’s one of the most difficult things you can do. Setting a clear and crisp vision is crucial to create an aligned organisation. Refining down into an elevator-pitch sized statement while avoiding generalisations, platitudes and (frankly) abstract jibberish is practically impossible.

Doing so outside a corporate environment I think is even more difficult – money is at least a straightforward motivation to hang a hat on. One of the best guides to doing this is Guy Kawasaki’s Art of the Start Manifesto, I particularly like the bit about making mantra.

The new mission for Fedora is:

Fedora creates an innovative platform that lights up hardware, clouds, and containers for software developers and community members to build tailored solutions for their users.

Unfortunately a few weasel words have crept in (“innovative”, “solutions”, “platform”), but I love the overall trust of it. The four foundations are pretty close to being a mantra and they’re indirectly reflected in this.

The main thing I find disappointing is that the mission ties in specifically to a few delivery mechanisms. Lighting up containers should be a consequence of the mission, and not be part of the mission, for my money. Containers are very relevant today – but are they going to be relevant in five year’s time?

Fedora is an operating system, the role of an operating system is to create an environment in which software can be allocated the resources with which to run. The end user value in having an operating system is precisely that you can run software easily. Having great support for containers is, right now, singularly important is being able to do that.

Let’s quickly thing about the future, though. Containers are one piece of technology, Kubernetes is a broader one. Day by day, I see more and more investment in k8s – to the extent that relatively soon we’ll need to think about k8s as an operating system in its own right. It’s never going to replace Fedora, and Fedora can run within k8s, but applications that run on k8s need to be quite specifically tailored for that – or even designed for that from the start. The whole story that k8s has is really about resource allocation.

Kubernetes isn’t the last word by any means. The true future is Serverless, which is coming at us at a rate of knots. Should this be part of mission? Right now, almost certainly not – but the mission should be the test. If the mission is about delivery of an environment in which people can run software, Serverless software will become increasingly relevant in that mission in the near future.

The really positive thing about the mission is that it can be used to test ideas. If something isn’t aimed at developers or the community, it likely doesn’t fall into the mission. Replacing legacy Unix is not part of the mission either.

If the redefined mission ends up being useful, it will be because it helps align the community and enables better, more consistent decisions to be taken – everyone will help push Fedora in the same direction. It will be great to see that happen.

Serverless, Put Simply. A big change to software development is coming.

Explaining Serverless technology

If you’re an IT or business leader, you’ve probably heard about serverless. Forward-thinking organisations are planning for servless now, because it’s a big change to how we build software. You don’t need deep tech knowledge to understand why – there’s nothing mystical about serverless. I’m going to explain what this is in simple terms and how it will affect software development practices.

Read More

Brand demolition

It was only just over a week ago that I posted about brand being the net result of action, and in the last few days United Airlines have decided to furnish me with the best example yet.

There’s nothing that speaks more volumes than how a company treats its customers, and while it’s not the case that all their customers are treated this poorly, the fact they will go this low is shocking.

Employees are not “brand ambassadors”; as the agents of your company they are the ones building your brand. Customers aren’t always right, but when they are happy and talk positively about your company, you build your brand. Marketing and advertising help build awareness of a brand, good logos and design will give people an intuition about your brand, but the rubber hits the road when your organisation does things.

So, what is strategy anyway?

It’s always interesting reading how other people view strategy, and Vince Law’s WTF is Strategy? is a very entertaining read. Like a lot of my posts, it’s quite digital product-oriented, but I think these principles are pretty general and should apply for most people.

What is interesting is that one of the examples he uses – taking a road-trip across the States – is exactly an example that I cover early on in “A Practical Introduction to Wardley Mapping“. It’s different in some notable ways – his journey is east-west while mine is north-south, because the goals are totally different – but it’s very insightful that he chose such a similar example to mine to illustrate the point. This also helps point out the differences in our approaches!

Read More

A business plan for Ubuntu

Back in 2010 I wrote a post about Canonical’s business direction, in response to something Bradley Kuhn had posted. Both he and I were worried about Canonical becoming reliant on an “open core” business model – worried not just from the perspective that it would dilute the principle of Ubuntu, but that frankly every time I have seen this executed before it has been a dismal failure.

The posts are worth re-reading in the context of Mark Shuttleworth’s announcement today that Ubuntu will be dropping a number of their in-house technologies and, more importantly, abandoning the explicit goal of convergence. I would also say, read the comments on the blogs – both Bradley and I found it deeply strange that Canonical wouldn’t follow the RHEL-like strategy, which we both thought they could execute well (and better than an open core one).

Of course, our confusion was – in hindsight – obvious. We weren’t seeing the wood for the trees. The strategy has since been spelled out by Simon Wardley in his rather good talks; one example is here:

It’s well worth to take the time to watch that and understand the strategy against RedHat; but it’s pretty easy to state: “Own the future, wait for it to come to us”. Let’s see why this is important.

Read More

Page 1 of 17