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.

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.

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.