Blog

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.

Gorm is the data access layer in Grails. I’ve been mostly away from Grails since 3.0 landed (for reasons).

I’ve recently been taking a look at how things have come along, and have continued delivering training on Groovy.

In the session I’m delivering there was some interest in Gorm as I walked people through it, and since I’ve been showing people the benefits of using Groovy for shell scripting and system automation, I thought, why not Gorm too?

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.

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!

TL/DR

• Microservices == distributed systems. RPC is well known for creating fragility in systems, Muon offers a way of building others kinds of APIs, based on Reactive principles while keeping your existing internal frameworks, languages and runtimes.
• Muon gives you very portable, polyglot message based APIs, across infrastructures. This lets you focus on the functionality you need for your business, rather than adopting a vendor best practice and becoming locked in.
• It is based on CSP, and is focused squarely on communication as a way of expressing interaction about state. This lets you build highly distributed systems without falling into the traps of
• This approach is implemented as Muon “protocols”, message based apis and defined interactions between services that implement well known communication and data architecture patterns. This lets you explicitly use particular architectures, such as event sourcing or SEDA, and know that it is correct, works well and is portable across languages, runtimes, frameworks and communication technologies (gRPC, Kafka, AMQP etc)
• It allows you to adopt advanced technologies as a tactical decision later on in your project, without impact on your codebase. This includes tech such as Kafka, Hazelcast and Cassandra, knowing that as you need to scale your system, you can.

I have been a big fan of the Reactive approach to build software for as long as its been around. My view on the world of Microservices today is that there are several strands you need to weave together to make your software thrive.

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?

…​

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.

No programmer likes to plan for their work to be taken offline and shutdown, but part of good antifragile thinking is allowing things that aren’t successful, to end. Applying that to Microservices, one of the natural parts of that architectural style is creating and destroying instances of a service. As part of the lifecycle of services, you sometimes have to create different versions of a service, and so manage the retiring of a previous version (although we try to avoid versioning where possible).

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.