Design patterns

May 5th, 2015

Refactoring large monoliths to microservices: strategies, risks and pragmatic reality

Large scale rewrites of systems are loaded with risk. You can address this by preparing the ground in advance and adopting an incremental approach, but a willingness to be pragmatic is essential.

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?

February 8th, 2015

Protocol buffers for .Net: protobuf-net vs protobuf-csharp-port

Google’s open source serialization format is an efficient way of passing platform-independent and version-tolerant data between end-points. Two very different implementations have emerged for .Net.

November 3rd, 2014

Why you shouldn’t create asynchronous wrappers with Task.Run()

Many developers confuse asynchronous operations with parallel execution. The essential difference is that an asynchronous operation is concerned with which resources you consume while parallel execution is more concerned with how many.

September 9th, 2014

CQRS is a state of mind rather than a cookie-cutter design pattern

CQRS is based on the simple notion that you use a different model to update information than the one to read it. This does not necessarily have to give rise to the same solution every time.

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.

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.

October 19th, 2013

Can APX help in developing usable and accessible APIs?

Given how important APIs have become in driving the reach of applications and services, it’s surprising how little investment is made in the usability of APIs as opposed to UIs. Perhaps the principals and techniques used by UX should be applied to developing more effective APIs…

July 16th, 2013

Managing change and version control for service interfaces

Change is an inevitable and even desirable part of distributed development. Managing the impact of that change is the difficult part, particularly when change affects the service interfaces that bind a distributed platform together.

June 17th, 2013

Netflix has abandoned OData – does the standard have a future without an ecosystem?

Netflix have closed their OData catalogue and EBay seem to have quietly put their implementation out to grass. With a shrinking ecosystem and no marquee services, does Microsoft’s data standard have a future?

May 21st, 2013

The generic repository is just a lazy anti-pattern

A generic repository is often used with the entity framework to speed up the process of creating a data layer. In most cases this is a generalization too far and it can be a trap for lazy developers.

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.

December 17th, 2012

REST services may not have standards, but they should follow conventions

REST is more of an architectural style than a set of standards. That said, a service should follow certain conventions if it is to be predictable and simple to work with.