Ashraf Mageed
@ashrafmageed.com
EDA | DDD | Microservices | Agile | Architecture
- Using events does not magically make you loosely coupled
- Using events does not mean you shouldn't care and understand what data your consumers want.
- Using events does not mean you shouldn't care and understand what data your consumers want.
November 16, 2025 at 7:04 PM
- Using events does not magically make you loosely coupled
- Using events does not mean you shouldn't care and understand what data your consumers want.
- Using events does not mean you shouldn't care and understand what data your consumers want.
What I've started noticing more and more lately is that managers preach psychological safety, empowerment and openness... until people disagree with them on something. Then it all goes out the window. I reckon it's correlated to the current job market conditions.
June 19, 2025 at 6:52 PM
What I've started noticing more and more lately is that managers preach psychological safety, empowerment and openness... until people disagree with them on something. Then it all goes out the window. I reckon it's correlated to the current job market conditions.
There is a fixed mindset in many organisations that makes change infinitely harder. There is an inexplicable clinginess to the status quo. New ideas are labelled "radical" and people bringing them are "purists".
June 17, 2025 at 7:47 PM
There is a fixed mindset in many organisations that makes change infinitely harder. There is an inexplicable clinginess to the status quo. New ideas are labelled "radical" and people bringing them are "purists".
I am no security expert, but making everything publicly accessible because "we implement 'zero-trust'" doesn't sit right with me. You instantly significantly increase the attack surface area and neglect 'defence in depth'.
June 11, 2025 at 6:03 PM
I am no security expert, but making everything publicly accessible because "we implement 'zero-trust'" doesn't sit right with me. You instantly significantly increase the attack surface area and neglect 'defence in depth'.
I was just told at work that we don't need OpenTelemetry and this Collector malarkey. We are already decoupled from any vendor - every microservice (400 in total) logs everything to stdout, we then have scrapers (managed/deployed individually, mind you, so huge maintenance overhead)
June 11, 2025 at 5:12 PM
I was just told at work that we don't need OpenTelemetry and this Collector malarkey. We are already decoupled from any vendor - every microservice (400 in total) logs everything to stdout, we then have scrapers (managed/deployed individually, mind you, so huge maintenance overhead)
Reposted by Ashraf Mageed
In databases (and lakes and warehouses), you handle data you have. In streaming, you handle data that is coming at you, while it is coming at you.
www.linkedin.com/posts/clemen...
www.linkedin.com/posts/clemen...
February 27, 2025 at 9:37 AM
In databases (and lakes and warehouses), you handle data you have. In streaming, you handle data that is coming at you, while it is coming at you.
www.linkedin.com/posts/clemen...
www.linkedin.com/posts/clemen...
How can an organisation accept that observability is essential and not optional when its people's mental model of distributed systems is simple lines and boxes where everything is predictable and known?
February 20, 2025 at 10:29 AM
How can an organisation accept that observability is essential and not optional when its people's mental model of distributed systems is simple lines and boxes where everything is predictable and known?
Joined a new company and took over an enterprise-wide initiative to improve logging/monitoring across their microservices arch. Directed the org towards OTel and Observability and have been extolling their virtues since only to be continually met with:
February 14, 2025 at 11:41 AM
Joined a new company and took over an enterprise-wide initiative to improve logging/monitoring across their microservices arch. Directed the org towards OTel and Observability and have been extolling their virtues since only to be continually met with:
Reposted by Ashraf Mageed
Started building a new "dotnet new" template for creating a library as a NuGet package, including @nuke.build build pipeline, unit tests, proper .editorconfig, Roslyn analyzers, a nice readme and more. See github.com/dennisdoomen...
GitHub - dennisdoomen/dotnet-package-template: A "dotnet new" template for a class library with all the necessary components to publish it on NuGet
A "dotnet new" template for a class library with all the necessary components to publish it on NuGet - dennisdoomen/dotnet-package-template
github.com
January 18, 2025 at 7:14 AM
Started building a new "dotnet new" template for creating a library as a NuGet package, including @nuke.build build pipeline, unit tests, proper .editorconfig, Roslyn analyzers, a nice readme and more. See github.com/dennisdoomen...
CRUD (micro)service usually have no, or very little, business logic under the guise of simplicity. However, this doesn’t simplify your system; it just relocates complexity.
January 17, 2025 at 2:12 PM
CRUD (micro)service usually have no, or very little, business logic under the guise of simplicity. However, this doesn’t simplify your system; it just relocates complexity.
Does an ARB fit with agile/modern development & Architecture? Should you try to make it fit? Regardless though having to re-book an ARB session (and wait for the next weekly one) every time there is a change to the design is not (never?) a good idea.
January 15, 2025 at 2:59 PM
Does an ARB fit with agile/modern development & Architecture? Should you try to make it fit? Regardless though having to re-book an ARB session (and wait for the next weekly one) every time there is a change to the design is not (never?) a good idea.
This.
If an event or a command is not a good fit in a particular part of the workflow, don't force it just because you chose choreography or orchestration to model the workflow.
If an event or a command is not a good fit in a particular part of the workflow, don't force it just because you chose choreography or orchestration to model the workflow.
When we think about orchestration vs. choreography, it doesn't really have anything to do with messaging vs eventing (commands vs. events).
1/
1/
January 14, 2025 at 12:10 PM
This.
If an event or a command is not a good fit in a particular part of the workflow, don't force it just because you chose choreography or orchestration to model the workflow.
If an event or a command is not a good fit in a particular part of the workflow, don't force it just because you chose choreography or orchestration to model the workflow.
Reposted by Ashraf Mageed
When we think about orchestration vs. choreography, it doesn't really have anything to do with messaging vs eventing (commands vs. events).
1/
1/
January 11, 2025 at 7:52 PM
When we think about orchestration vs. choreography, it doesn't really have anything to do with messaging vs eventing (commands vs. events).
1/
1/
Reposted by Ashraf Mageed
Read this thread from the top for my replies to "you don't need a queue if you already have a database"
Supporting competing consumers and assigning jobs to processors exclusively are the key features of a queue.
December 18, 2024 at 7:18 AM
Read this thread from the top for my replies to "you don't need a queue if you already have a database"
Reposted by Ashraf Mageed
3. Engineering output is not your constraint
Theory of Constraints 101. Customer value is gated somewhere else in your system or the broader value chain, and how fast you type is not the limiting factor.
"Any improvement not made at the constraint is an illusion" -- Eli Goldratt, The Goal
Theory of Constraints 101. Customer value is gated somewhere else in your system or the broader value chain, and how fast you type is not the limiting factor.
"Any improvement not made at the constraint is an illusion" -- Eli Goldratt, The Goal
January 9, 2025 at 3:53 PM
3. Engineering output is not your constraint
Theory of Constraints 101. Customer value is gated somewhere else in your system or the broader value chain, and how fast you type is not the limiting factor.
"Any improvement not made at the constraint is an illusion" -- Eli Goldratt, The Goal
Theory of Constraints 101. Customer value is gated somewhere else in your system or the broader value chain, and how fast you type is not the limiting factor.
"Any improvement not made at the constraint is an illusion" -- Eli Goldratt, The Goal
"Platform" is the new "Microservices". We need a "you need to be this tall" to build one. A mishmash of disparate modules with limited docs, no self-service, long lead time to provision (on-prem K8s), no team that owns it + (obviously) mandating its use... is not a platform. That's been my day...
January 8, 2025 at 8:30 PM
"Platform" is the new "Microservices". We need a "you need to be this tall" to build one. A mishmash of disparate modules with limited docs, no self-service, long lead time to provision (on-prem K8s), no team that owns it + (obviously) mandating its use... is not a platform. That's been my day...
Used the time wisely though :)... read a chapter from a technical book and now watching a @kevlin.bsky.social talk: www.youtube.com/watch?v=21z2...
January 7, 2025 at 6:39 AM
Used the time wisely though :)... read a chapter from a technical book and now watching a @kevlin.bsky.social talk: www.youtube.com/watch?v=21z2...
Ahh.. the dreaded 4:30 am internal 'wake-up' alarm when you've spent the previous day & night struggling to resolve a technical issue. Great start to the year!
January 7, 2025 at 6:35 AM
Ahh.. the dreaded 4:30 am internal 'wake-up' alarm when you've spent the previous day & night struggling to resolve a technical issue. Great start to the year!
Finally... www.ashrafmageed.com/the-hidden-c...
January 5, 2025 at 1:29 PM
Finally... www.ashrafmageed.com/the-hidden-c...
CRUD services seem straightforward on the surface but underneath this apparent simplicity lurks a hidden complexity that can erode the very principles that microservices are meant to uphold - loose coupling and high cohesion.We must think beyond CRUD to get the best from a microservices architecture
January 4, 2025 at 4:25 PM
CRUD services seem straightforward on the surface but underneath this apparent simplicity lurks a hidden complexity that can erode the very principles that microservices are meant to uphold - loose coupling and high cohesion.We must think beyond CRUD to get the best from a microservices architecture
I haven't blogged in a while - a couple in the last 12 months. It's like riding a bike, though, so words should flow once I start.. shouldn't they??! A recent debate about CRUD (micro)services inspired me to post something, but it's taken me 2 weeks!!
January 4, 2025 at 3:36 PM
I haven't blogged in a while - a couple in the last 12 months. It's like riding a bike, though, so words should flow once I start.. shouldn't they??! A recent debate about CRUD (micro)services inspired me to post something, but it's taken me 2 weeks!!
I want to start blogging again... but boy I hate writing. Writing does help me solidify my understanding & discover gaps in my knowledge but I wish I could do all that some other way. Why aren't there forums where like-minded individuals can talk about tech things and learn together? Judgement free!
December 29, 2024 at 11:03 AM
I want to start blogging again... but boy I hate writing. Writing does help me solidify my understanding & discover gaps in my knowledge but I wish I could do all that some other way. Why aren't there forums where like-minded individuals can talk about tech things and learn together? Judgement free!
What's funny is that those same people wouldn't design their classes that way. This CRUD way of working seems to only be prevalent when dealing with (micro)services.
We have been doing this microservices thingy for over a decade now - and SOA for even longer... why do people still think CRUD (micro)services are a good idea?
December 26, 2024 at 2:39 PM
What's funny is that those same people wouldn't design their classes that way. This CRUD way of working seems to only be prevalent when dealing with (micro)services.
I'm really enjoying using #DomainStorytelling in a personal project - maybe even a tad more than EventStorming, dare I say? Would have to try it in a more complex project first but I just love how natural the modelling flows.
December 25, 2024 at 7:25 PM
I'm really enjoying using #DomainStorytelling in a personal project - maybe even a tad more than EventStorming, dare I say? Would have to try it in a more complex project first but I just love how natural the modelling flows.