DEV Community: Rich McIntyre

Exploring Modern Architectures: A Shallow Dive into Modular Monoliths, Event-Driven Architecture, and Edge Computing

Rich McIntyre — Tue, 11 Mar 2025 12:06:02 +0000

In an ever changing technical landscape, modern architectures are becoming increasingly important for businesses to stay competitive and efficient. Getting your architecture right is the difference between scaling and delivering fast with longevity and not. So, you need to make good choices.
I often help organisations look at the architecture patterns they employ, and together think about technical strategic opportunities. In one of these recent sessions, there were 3 brilliant architectural approaches that I thought it would be worth sharing.

Modular Monoliths: The Best of Both Worlds

Ever had challenges with micro-service network complexity and deployment orchestration? Ever found a large evolving monolith turn into spaghetti with slow cumbersome test cycles and functionality bloat that becomes hard to understand?

I first came across the modular monoliths through the excellent Elixir programming language, they have a concept of 'umbrella projects', that you can set up through its default build tool 'Mix'.
As a developer I would often introduce modules immediately as I set up an app. This would allow me and the team I was working with to very clearly work within the domain boundaries, and to easily separate the logic into a brand-new service should I need to. Recognising shared logic and domain specific logic and creating a logical separation early, helps you to create elegant, maintainable apps.
Each module will have clear entry points through its router, you do not access other modules apart from via it's routing mechanism, this is to ensure that you do not re-create a spaghetti monolith by accident.
You can then either deploy the application as a monolith, if you need to future separation, you can have some routing logic that will allow subdomains to map to paths, so externally they appear like individual services. You can also deploy to multiple compute instances and despite services all having the save code deployed to them, similar domain to path mapping can ensure each service only invokes the module that is dedicated to a given domain.

We have found the benefits of a Modular Monolith include:

Single or multiple deployment units
Less Operational Overhead
Separation of Concerns
Focused Ownership
No Network Latency
Optimized Resource Usage
Selective & Efficient Scaling
Reduced Infrastructure Costs
Potential Lower Development Costs

Modular Monoliths offer a balanced approach, combining the simplicity of monolithic architecture with the flexibility of micro-services. This pattern allows developers to build applications as a single, cohesive unit while maintaining clear boundaries between different modules. This approach not only simplifies deployment but also enhances maintainability and scalability.

Event-Driven Architecture: Events as a first-class citizen

We often have events within our architectures, however are they truly event-driven? What is the difference between utilising events being event-driven?

One way that you might think about this problem, is to take out all other communication methods such as REST from the internal communication of your system, would it still work? One reason micro-service architecture has been seen as brittle and not fault tolerant, is its high reliance on HTTP. HTTP is great, it scales the entire internet. However, failure patterns are not very elegant and are often not implemented consistently.
Event-driven architecture (EDA) is a powerful pattern where components communicate to each other primarily through events, EDA enables loose coupling and asynchronous communication providing fault tolerance and greater control of failure scenarios.
This is especially useful when you have many inconsistent dependencies, your messaging service can handle much of the abstraction for you, where the common language of communication of the service is the event message itself. Event streaming technologies such as Kafka or Azure's Service Bus, allow you to register message schemas, that be used for validation.

Some of the benefits include:

Loose Coupling
Independent Development
Asynchronous Communication
Focused Ownership
Fault Tolerance
Retry Mechanisms are easier to implement
Easier Interfacing
Parallel Processing

One of the key advantages of EDA is its ability to handle high availability services at a national scale. For example, in government projects, event-driven systems ensure that critical events, such as passport applications, are processed reliably and efficiently. This architecture also supports parallel processing making it ideal for systems that evolve frequently.

Edge Computing: Bringing Processing Closer to the User

Edge computing turns upside down the way we think about compute, deployment and cloud platforms.

By moving computation closer to data sources and user, edge computing reduces latency, makes systems feel more responsive and enhance the user experience. This is particularly useful for applications that require close to real-time processing and low latency.
In practice, edge computing has been used to create super-fast and efficient micro apps that can be deployed to the edge network. This not only improves performance but also simplifies deployment and management. However, there are still challenges, for example data centralisation (see this excellent blog post from Alex Mitchell), which need to be addressed to fully run with this

Some other benefits we have found:

Extremely cost effective
Intelligent Web Application Firewall (WAF) built in (Cloudflare)
Performant (we have seen sub 10 millisecond responses from workers)
Fast to deploy
All the good sides of Serverless (Scalability, cost, no maintenance)

We have found Cloudflare workers particularly effective, deployment times are extremely fast and the supporting features around it, including KV stores, databases and queues make them very powerful. In some cases, it might be possible to use Cloudflare as a cloud platform in itself.

Conclusion

Modern architectures like modular monoliths, event-driven architecture, and edge computing are evolving the way we build and deploy software. By understanding and implementing these patterns, businesses can achieve greater scalability, fault tolerance, and efficiency. As we explore these exciting approaches further, it's clear there will be some powerful solutions available to us in software development.

Using GitHub Copilot in a whole bunch of teams and projects, this is what we discovered

Rich McIntyre — Fri, 03 May 2024 14:56:29 +0000

At BJSS we are super excited about new AI tooling coming out. We have been trying out various tools, however, the GitHub Copilot is a tool that we felt could give engineers instant benefits, we were also excited to see if the improved velocity improvements that GitHub has been advertising were true.

At the time of writing GitHub claims Copilot can help you achieve 55% faster coding. We of course know that being a software engineer is not just about coding, so we were not expecting a 55% efficiency, but we were expecting some exciting pace.

We gave Copilot to approximately 40-50 developers over 4 different clients. Before each team got going we gave them a feature overview and demo so that they could get up and running as fast as possible.

We then had biweekly check-ins and retrospectives to find out how developers felt that their work had been impacted by using AI-based tooling.

So what did we learn?

Here is some of the feedback the engineers gave us. Here is a picture of what the engineers told us by category.

Test Code

Creating new unit tests quite quickly
The few times I asked it to write some test code it gave me something that did cover the test but was very poor and difficult to understand
Was good at ‘generating’ unit tests that were similar to other tests in the file (eg. an undefined case test)

Productivity

It was Useful for quickly understanding blocks of code
Useful in suggesting code snippets that speed up productivity
It did not help much whilst working on bug tickets
Extra time was needed to determine if the suggestion is helpful
Useful for quickly changing simple patterns
Suggestions were often poor and stopped me from using IDE suggestions
Seemed to be a handy paste without having to find the thing to copy.
Existing IDE tools provide alternative useful functionality (not always compatible
Would occasionally be able to produce a function after writing a description for it, but would then have to analyse the function in detail to ensure it was what I expected
I cannot go back to life without Copilot, the accuracy when it comes to refactoring code has helped tremendously
I find it really useful for repetitive tasks which allows more time on the complex stuff
The main benefit I’ve had is when it autocompletes simple code that takes little brain power but sinks time to write. 13. Sometimes it’s quicker to write what I want code to do in plain English than write the code itself, and then with the text prompt Copilot takes care of the rest.
It’s a huge relief on cognitive load
It's good for repetitive tasks when it works. I've found it's sometimes quite slow for me and sometimes doesn't give suggestions when you expect it to.
I have found it super useful for updating pipeline files as well - if I add a bunch of vars, when i go to call those vars in the pipeline it remembers them and suggests them nicely

Quality

No effect on quality because the only suggestions I accepted were patterns I was already using
Code generated was of similar quality to existing code…
Handy to test on different approaches/patterns

Features and Integration

Chat is more useful than code complete
Chat was unable to help me with a specific issue
The chat not being available for JetBrains meant I couldn’t use it to all of its abilities
Useful feature: explain this
I disabled it in WebStorm but try it occasionally in VSCode.

Summary

From one snapshot we took, there was:

14 Positive sentiments
8 Negative sentiments
6 Neutral sentiments

Overall the sentiment was positive....

Users felt that chat features, explain, etc were of high benefit.
However, users of JetBrains/IntelliJ IDEs had a worse experience due to lack of chat feature available at the time and native auto-complete being missed.

GenAI tools were particularly useful for writing unit tests, however, were not as useful for bugs, migration of code, newer coding standards (eg. Vue 3), or emulating current repo coding styles. Code quality was unaffected but required verification and sometimes fixing to ensure it aligns with current standards and practices.

Closing thoughts

I must admit I was a little disappointed that this was not quite the HUGE success that I was anticipating, however, engineers did feedback that they missed the tool when they no longer had access to it.

The biggest gaps seemed to be a lack of understanding of the business context, project coding styles, and also an understanding of particular versions of language and frameworks.

Saying this, GenAI dev tools are constantly improving. Today I learned Amazon Q developer is now available as a general release. I am also keen to use GitHub Copilot Enterprise which also promises to address some of these concerns.

We also realised that it is not merely having a tool that speeds up AI-driven delivery, but changing and improving workflows whilst using GenAI tooling is also imperative.

We are working on this right now which we will share with you more soon!

Going forward

At BJSS we are confident that these tools are here to stay and are likely to radically change how we create software. We will continue to make assessments of new tools as they come out and will publish some of our findings. We are really excited about the productivity gains our teams will see in future!