October 3rd, 2016

What’s so bad about monoliths anyway…?!

Don’t get me wrong – I am an advocate of decomposing functionality into autonomous services. My reservation is that you need to have a lot of prerequisites in place before you can start leveraging microservices.

June 28th, 2016

Should microservices share technologies and platform capabilities?

Should agile teams be encouraged to share capabilities or be given total autonomy over their technology choices? For larger organisations this can become a trade-off between economies of scale and speed of delivery.

May 5th, 2016

Managing services that don’t have clear code ownership

How do you organise code ownership for services that do not align conveniently with team or organisational boundaries?

February 1st, 2016

Data design for event-driven architecture: autonomy, encapsulation and ordering

When you’re implementing an event-driven architecture, the design of your events is absolutely critical to realize the benefits of loose coupling.

December 12th, 2015

Pragmatic REST: APIs without hypermedia and HATEOAS

If you’re not using HATEAOS then you’re not using REST. That’s true enough, but in many cases adopting HATEOAS doesn’t deliver much value beyond architectural purity.

November 26th, 2015

Comparing nServiceBus and MassTransit: Do we still need .Net integration frameworks?

Both nServiceBus and Mass Transit plugged an important gap in Microsoft’s integration landscape, but do they have a role in a future that is likely to be dominated by diverse technologies and autonomous agile teams?

October 15th, 2015

Using the REST API connector as a data source in Informatica Cloud

It can be pretty straightforward to read REST API resources using Informatica Cloud – so long as you know which levers to pull and your data is in a sympathetic format.

July 25th, 2015

Can cross-cutting concerns really exist between services?

You might be able to identify cross-cutting concerns in a monolith, but in a service-orientated world they should melt away into specific implementations.

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.

April 20th, 2015

Microservices, REST and the distributed big ball of mud

The “big ball of mud” describes a system architecture that is sprawling, sloppy and haphazard. That’s precisely how you’d describe some emerging microservice architectures.

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.

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.

December 16th, 2014

Don’t assume message ordering in Azure Service Bus

Azure Service Bus can provide first-in-first-out messaging in theory, but this is not the same as guaranteeing the order in which your messages are processed.

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.