Favourite posts

September 16th, 2018

Building Twelve Factor Apps with .Net Core

Twelve factor apps provide a methodology for building apps that are optimised for modern cloud environments. It’s only been achievable in the Microsoft world since the advent of .Net Core.

July 29th, 2018

Autonomous bubbles and event streams: Pragmatic approaches to working with legacy systems

It’s easy to get caught up in unrealistic notions that you can re-write a legacy system or gradually decompose it. There are other, more pragmatic approaches that can help to modernise architectures and enable new development.

February 16th, 2018

Relax. There’s no conflict between architecture and agile.

Agile teams still need to make architecture decisions, but in supporting them architects should seek “just enough” architecture over “big design up front” and practical solutions over large-scale abstract thinking.

January 28th, 2017

Why agile software architects should write code

No architect will ever admit to being out of touch with software development. However, unless you are writing code then it’s difficult to avoid becoming an “ivory tower” or “PowerPoint” architect that can only discuss systems in the abstract.

January 7th, 2017

Event stores and event sourcing: some practical disadvantages and problems

Event stores and event sourcing are a powerful idea, but they can be vulnerable to a number of technical and operational challenges when faced with real world complexity.

July 29th, 2016

Designing an event store for scalable event sourcing

Event sourcing can scale very nicely, though this does depend on a number of key design decisions for the underlying event store.

March 9th, 2015

How big is a microservice?

We know that micro services are small and focused by design – just how small is this in practice?

January 4th, 2015

Why REST is not a silver bullet for service integration

REST is sometimes described as the next “evolutionary step” in service integration. The problem is that REST provides too much of a “dumb pipe” to support genuinely decoupled, fault-tolerant service integration.

November 22nd, 2014

The RESTafarian flame wars – common disagreements over REST API design

Debates on the finer points of REST can bring out the worst in people as they seek to define what is and is not “RESTful”. In most cases the debate is unlikely to make the difference between success and failure for an API.

August 21st, 2014

Messaging shouldn’t be used for queries

When developers first start using messaging they can be tempted to use it as a brand new hammer for every nail. Messaging brings a lot to the party, but it isn’t necessarily a suitable transport for fast, synchronous query processing.

July 9th, 2014

The problem with tiered or layered architecture

An architecture based on tiers or layers is too inflexible to deal with the more flexible demands of modern systems, particularly when you working with high-volume systems that require distributed processing.

June 12th, 2014

Are microservices just SOA “done properly”?

There’s nothing really new about many of the ideas that underpin microservices. Are they just an agile re-branding of SOA?

May 4th, 2014

Eventual consistency and the trade-offs required by distributed development

Developers who have been brought up on the certainties of ACID transactions often have a problem trusting eventual consistency. Once you start exploring the requirements in more depth this really so much of a handicap.

April 21st, 2014

Hackable URIs may look nice, but they don’t have much to do with REST and HATEOAS

Structured and “Hackable” URIs are a staple part of SEO-friendly websites. Although developers generically expect to see them in HTTP-based APIs, they should be irrelevant to consumers of a fully RESTful API that leverages HATEOAS.

March 12th, 2014

What role do architects have in agile development?

Agile principals encourage self-organising teams to take ownership of solutions. This doesn’t leave architects out in the cold, but it does require a more engaged role based on influence rather than governance.