Tech

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.

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.

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.

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:

The promises of adopting the cloud for your software are enticing. Effectively limitless scalability, large reductions in capital expenditure, efficiency savings in staffing through automation. An exciting prospective, and one that has being brought into even greater focus by the rise and rise of Microservices.

Not all is sweetness and light, however. There is significant investment required in ensuring your organisation and software can make best use of the new environment of the cloud. That investment in technology, training, development approaches and aligning the business with the new adaptable technology world can be significant, and the potential for a misstep to cost and lead your organisation into a dead end is present and you are right to be wary.

Peter Ledbrook recently wrote a blog post about the future of Grails, which sparked some deep thoughts about where Grails is heading as a platform.

As a long-term Grails user with interests in programming in the large, functional languages, DDD, CQRS, and high-volume HTTP, I’ve been contemplating what the future holds for this framework.

The Changing Landscape

The industry has changed significantly since Grails was born. Grails emerged from the Spring/MVC consensus - essentially designed to be “Java/Spring web development done right.” It was, and continues to be, a better Spring MVC paired with a better Java (Groovy). This approach has been beneficial to the industry.