Coding

I’ve just completed migrating my blog from WordPress to a static site generator. This new setup gives me the best of both worlds: the simplicity and security of static files with the convenience of a visual editor.

Why I Made the Switch

After years of maintaining WordPress sites, I wanted something simpler:

• No database to maintain - Everything is stored in Git
• Better performance - Static files served from a CDN
• Enhanced security - No server-side code to exploit
• Version control - Every change tracked in Git
• Simple backups - Just clone the repository

The Technology Stack

I chose a modern JAMstack approach:

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.

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?

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

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

Gradle, NPM, Lein, Maven, Docker, Ansible, Kubernetes, Grunt …​ The list goes on (and on, and on). Developer tooling, constantly re-invented for the modern age.

Microservices projects put particular pressures on development teams , even without polyglot, you end up adding in a fair amount of automation tooling (Docker anyone?) that is patchily integrated into the core developer tooling. Every time you add in docker support to gradle or grunt, the more locked you are to that language, making moving away that much harder.

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!

Since coming back to freelancing, I’ve (re)started a set of projects with clients, managing them end to end. This means that I need a deployment environment somewhere that I can throw stuff into. I have much experience with Cloud Foundry (I deliver training for Pivotal on it), but its a little heavy for my needs, and I want to have relatively small stateful containers that don’t take up a full box.

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?

…​