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.

When approaching development of Microservices, it’s often easy to think of the services themselves as the valuable pieces of your system. Each service you add gives you more functionality, and so more value. For the majority of systems we have built and reviewed during our consultancy, we have found that the system itself is of fairly marginal value. Instead, the data that it contains and the intelligence it can provide based upon that data is what is actually valuable. This seems a subtle, even academic distinction, but it is important and putting it at the forefront of your mind during design has significant repercussions on the way you build your services and the way that they interact with each other.

When building microservices, you have to naturally distribute your application around a network. It is almost always the case that you are building in a cloud environment, and often using immutable infrastructure.

The Challenge of Dynamic Service Location

In traditional monolithic applications, components communicate through in-process method calls. With microservices, these components are distributed across a network, and their locations can change dynamically due to:

• Auto-scaling events
• Service failures and recovery
• Deployments and updates
• Infrastructure changes
• Container orchestration

This dynamic nature makes hardcoding service locations impractical and brittle. Service discovery provides a solution by enabling services to dynamically find and communicate with each other.

A question often posed to us during our research and project work is “how should I secure a Microservice?”

When it comes to securing microservices, two primary approaches dominate the landscape: session-based security and OAuth/token-based security. Each has its strengths and weaknesses, and understanding these differences is crucial for making the right architectural decisions.

Session-Based Security

Session-based security represents the traditional approach to web application security. In this model:

All Hail the Command Object

This is a follow on to Simplicity in Web Architecture – Beware the Stateless Service

In that article, I gave my opinion on the Stateless Service programming model, and why I think it has been overused and touched on some of the issues it has caused.

It developed out of my unhappiness with the way I see code layed out in many Spring and Grails applications. The Service layer becomes stuffed with all the important logic, kept away from the domain and without much in the way of support to be had from the excellent Object Oriented language that Groovy is.