Best-Practices

I’ve been working with the team at Aurena in Austria since the beginning of 2021. It’s been a lot of fun, and interesting work.

The Journey with Aurena

Working with Aurena has been an exciting journey in helping them digitize their distribution process. As part of this effort, I built two microservices using Apollo Federation that form a critical part of their GraphQL API infrastructure.

Identifying Performance Issues

During development, we identified significant performance issues in our GraphQL API design. Using Elastic APM, we were able to analyze and pinpoint inefficient database queries that were impacting our API response times.

I recently stumbled across an interesting discussion article by @BenLugavere, “You’re not going to replay your event stream”, from back in 2018.

It’s an interesting read to spawn a discussion from, I recommend you have a look, I’ll wait …

I don’t know Ben, however he did invite a discussion on his article, so I will discuss it, as the subject is fairly timeless.

Although, I’m sure he didn’t imagine I would do it years later, but I’ve been away, meh

Without a doubt, Microservices as an architecture has grasped the imagination of modern development like no other.

We’ve found that, contrary to what many will tell you, it defies tight definition. Specifying how microservices should interact with each other, how they should store and master data, and how they should be deployed is great for a conference talk, but the style has been adopted too broadly now to be prescriptively tied down by anyone. Opinions abound, and yet you will find no consensus in what microservices actually are beyond the use of some form of effective isolation, usually network based.

The Original DRY, WET and Slogan Based Development

Hopefully, you now understand some of my pain when I’m arguing against DRY, and arguing against deep abstractions. The original definition of DRY though, Single Source of Truth etc, that’s ok right? I mean, WET (Write Everything Twice etc) just sounds so bad, and it’s the opposite of DRY, right?

Well …​ no, not really. This is development by slogan, pure and simple. Luke is right to fear this, it leads to dogma and dogmatic position taking and so to endless, needless, debate and argument over developer practices.

Don’t Repeat Anything == The Tower of Coupling

Copy and Paste, it’s bad. We have this drilled into us as received knowledge. We must build abstractions to avoid copying code, or concepts that seem similar, at all costs. We must do this, or we are bad developers and we’ve built a WET (Write Everything Twice .. etc) system, which isn’t DRY, so it’s bad.

I did a fun little talk a while ago that touched on this (seriously, go and do something a little silly every so often, it’s fun), and pointed to the problem that is inherent in applying DRY too broadly; Coupling.

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 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:

Recently (June 2015), I gave a talk at the DDD Exchange at Skills Matter in London.

This was a little last minute! The (then Simplicity Itself) CTO, Russ Miles, was originally scheduled to deliver at the conference, but he had to be out of the country visiting one of our partners and so I was drafted in to deliver.

This is a talk I’ve wanted to give for a long time, so while it was a little rough around the edges, the message is something we’ve been working with for a while.

The software development industry has an enduring fascination with finding the “silver bullet” - that one methodology, practice, or tool that will solve all our problems. From the early days of computing to today’s DevOps and microservices movements, we’ve seen wave after wave of “best practices” that promise to revolutionize how we build software.

But is this constant search helping or hindering us?

A Brief History of Silver Bullets

Looking back over the decades, we can see a clear pattern: