Favourite posts
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.
February 21st, 2014
Lean development’s “last responsible moment” should address uncertainty, not justify procrastination
Deferring decisions to the “last responsible moment” can help you to adapt to the inevitable uncertainty that comes with agile development. The risk is that it can become an excuse for uncertainty that undermines development velocity.
January 13th, 2014
Identifying the sources of system coupling in service orientated architectures
Every system has some level of coupling. After all, systems need to collaborate and in doing so they will inevitably share some characteristics of language and behaviour. It’s important to recognise where coupling occurs and the impact it has on stability and flexibility.
February 22nd, 2013
A shared database is still an anti-pattern, no matter what the justification
Shared databases risk turning into performance bottlenecks that encourage close-coupling and create a single point of failure. There’s no justification for using them to integrate processes and applications.
July 2nd, 2012
How not to use dependency injection: service locators and injection mania.
Development teams can struggle with dependency injection, often because they don’t have a clear understanding of how best to use it.
April 30th, 2012
Why refactoring code is almost always better than rewriting it
Developers and architects like to build things, so their initial impulse is often to flatten the place, lay some stronger foundations and build something impressive. It can be difficult to get them excited about incremental innovation, even when this is generally the most sensible approach from both a technical and commercial perspective.