Technology

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.

This article was spawned from a conversation I had with Ben Wilcock on his article about building an event sourced system on Cloud Foundry using Axon, which you can read here. We covered some interesting topics, including some critiques of the model so he encouraged me to write up my thoughts on Event Architectures.

No small topic there, thanks Ben!

This is an interesting topic, with a lot of potential pitfalls.

Recently I read an article on the concept of Entity Services over at InfoQ by Michael Nygard (and written up by Jan Stanberg). I’m not attempting to comment deeply on the article itself, only on the subject.

This is a topic I’ve spent an inordinate amount of time on over the years, you can see my thoughts in many a blog post and talk.

In talk form, I give a rundown of the problem and the issues it will create here while introducing the Muon project.

This article introduces a project I’ve been working on for the past few years in one form or another. Muon

For the past bunch of years, I’ve been working with distributed systems, often with a messaging component. This is a fun and rewarding part of software development, up there with UI development. It’s fairly involved, and often hard, but covers lots of different areas, both deeply theoretical and very practical. Once you solve an issue involving a race condition that requires networks, heavy load and specific hardware to trigger, you become far more interested in the world of concurrency, networking and spreading beyond the regular languages you are used to!

I’m currently finishing cleaning up a new application framework built upon the Muon communications toolkit, called Newton

In this framework, we provide support for building Event Sourced Aggregate Roots , Stream processed Views, long running transactional Sagas, commands and general event handling. Lots of good things.

I want to describe the Aggregate Root handling, as I had an epic fight with Spring/ Java Generics today that left me somewhat drained!

This article was originally posted at simplicityitself.com.

Simplicity Itself has now closed, and so I have moved my articles here.

If you would like to read up on why it closed – See here

When talking to clients, both current and potential, at conferences, users groups and the like, the question arises often, “what is a Microservice?”

In many respects, it’s a question that defies a single answer.

Since we’re a consultancy specialising in Microservices, we did a review a while ago with our clients and partners (some of you may remember), asking this very question!

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.

My good friend Peter Ledbrook has been pondering the question how can we share code between microservices

This is something we’ve had the opportunity to experiment with, on new projects and also longer running systems. This has given us some insight, which I’m happy to share here.

The process for building a new microservice is pretty well established by now.

• Define the service contract
• Expose on a network (somehow, http, messaging, or maybe https://muoncore.io[Muon])
• Profit?

…​

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.