Philosophy

Building distributed systems has taught me more about philosophy than any book ever could. When you’re designing systems that must coordinate across unreliable networks, you quickly encounter fundamental questions about truth, consensus, and the nature of communication itself.

The CAP Theorem as a Life Lesson

The CAP theorem states that distributed systems can only guarantee two of three properties: Consistency, Availability, and Partition tolerance. This isn’t just a technical constraint—it’s a fundamental truth about any system involving multiple independent actors.

This article was spawned from a conversation I had with Ben Wilcock on his article about building an event sourced system on Cloud Foundry using Axon, which you can read here. We covered some interesting topics, including some critiques of the model so he encouraged me to write up my thoughts on Event Architectures.

No small topic there, thanks Ben!

This is an interesting topic, with a lot of potential pitfalls.

This article was originally posted at simplicityitself.com.

Simplicity Itself has now closed, and so I have moved my articles here.

If you would like to read up on why it closed – See here

When talking to clients, both current and potential, at conferences, users groups and the like, the question arises often, “what is a Microservice?”

In many respects, it’s a question that defies a single answer.

Since we’re a consultancy specialising in Microservices, we did a review a while ago with our clients and partners (some of you may remember), asking this very question!

Without a doubt, Microservices as an architecture has grasped the imagination of modern development like no other.

We’ve found that, contrary to what many will tell you, it defies tight definition. Specifying how microservices should interact with each other, how they should store and master data, and how they should be deployed is great for a conference talk, but the style has been adopted too broadly now to be prescriptively tied down by anyone. Opinions abound, and yet you will find no consensus in what microservices actually are beyond the use of some form of effective isolation, usually network based.

The Original DRY, WET and Slogan Based Development

Hopefully, you now understand some of my pain when I’m arguing against DRY, and arguing against deep abstractions. The original definition of DRY though, Single Source of Truth etc, that’s ok right? I mean, WET (Write Everything Twice etc) just sounds so bad, and it’s the opposite of DRY, right?

Well …​ no, not really. This is development by slogan, pure and simple. Luke is right to fear this, it leads to dogma and dogmatic position taking and so to endless, needless, debate and argument over developer practices.

Don’t Repeat Anything == The Tower of Coupling

Copy and Paste, it’s bad. We have this drilled into us as received knowledge. We must build abstractions to avoid copying code, or concepts that seem similar, at all costs. We must do this, or we are bad developers and we’ve built a WET (Write Everything Twice .. etc) system, which isn’t DRY, so it’s bad.

I did a fun little talk a while ago that touched on this (seriously, go and do something a little silly every so often, it’s fun), and pointed to the problem that is inherent in applying DRY too broadly; Coupling.

I recently had a thought provoking exchange on Twitter with Luke Daley who is a Gradle developer, creator of the Ratpack web framework and all around awesome fellow.

We were briefly discussing DRY, aka Don’t Repeat Yourself, that great maxim of modern software development. My opening gambit was that ‘DRY totally sucks’ (because well, Twitter..). Luke picked me up on this, asking for a more nuanced view, more depth. His entirely reasonable request, to not ‘propagate software development by slogan’, which I’ve unashamedly stolen as my title is one we should all pay attention to.

No programmer likes to plan for their work to be taken offline and shutdown, but part of good antifragile thinking is allowing things that aren’t successful, to end. Applying that to Microservices, one of the natural parts of that architectural style is creating and destroying instances of a service. As part of the lifecycle of services, you sometimes have to create different versions of a service, and so manage the retiring of a previous version (although we try to avoid versioning where possible).

Recently (June 2015), I gave a talk at the DDD Exchange at Skills Matter in London.

This was a little last minute! The (then Simplicity Itself) CTO, Russ Miles, was originally scheduled to deliver at the conference, but he had to be out of the country visiting one of our partners and so I was drafted in to deliver.

This is a talk I’ve wanted to give for a long time, so while it was a little rough around the edges, the message is something we’ve been working with for a while.

The software development industry has an enduring fascination with finding the “silver bullet” - that one methodology, practice, or tool that will solve all our problems. From the early days of computing to today’s DevOps and microservices movements, we’ve seen wave after wave of “best practices” that promise to revolutionize how we build software.

But is this constant search helping or hindering us?

A Brief History of Silver Bullets

Looking back over the decades, we can see a clear pattern: