Martin Fowler

And I think I have a reason why.

And I think the reason why is because the famous article that was released on Martin Fowler's website by Martin Fowler and James Lewis, I believe it was in 2013, that really, they didn't originate the term, but they super popularized it.

In fact, I know by personal insight that is still still the most visited page on Martin Fowler's site to this day is that microservices page.

And I think it served a really, really important public service because it delineated what it is, but more importantly, what it's not.

And I think a lot of what leads to the trough of disillusionment in the hype cycle is people using the hypey thing for something it's wildly inappropriate for.

How about micro front ends? Ooh.

Ooh is right.

This was, wasn't this an interesting transformation in the past 12 years where, as Neil's fond of pointing out, we really, based on Martin Fowler and James Lewis's article, really sort of misinterpreted microservices.

The technical part wasn't as important.

So One of those realizations came to me in 2007 when I learned, well, actually, it goes back to 2005 when I read, maybe beginning of 06, when I read Martin Fowler's events sourcing initial article.

I think he published it in December 2005.

But he saw it was like, you know, this fun thing you could try, you know, rewind your application, insert an event to see what would happen if you had that, and didn't really treat it very seriously, which is kind of funny because then he had the LMAX disruptor pattern and all this other stuff, but Anyway, I don't want to digress too far.

And so then I come back to event sourcing because for me, I'm always like the debug ability.

It's one of the big features where like someone goes, this thing happened.

What happened? And I love the Martin Fowler article because he kind of described a few different ways to do event sourcing.

And kind of my like dipping my toes in the water was, hey, instead of trying to like aggregate from an event log and close the books every month and kind of figure that out, let's just log every event.

But one of the things that really gained, uh, some popularity here, uh, was the migration path to, let's say, microservices or even service-based.

So o- one of the, um, I'll say words of advice from, uh, Neal's, uh, colleague, Martin Fowler, uh, was, and also Sam Newman offered this advice, as well as, wow, um, Simon Brown-

Mm

... as well as both of us, is if you're not sure, uh, if you're gonna need to scale, or you're not sure where you wanna end up-

The strangler fig approach is the default recommendation for most teams that have genuinely outgrown low code.

Martin Fowler described this pattern back in 2004.

New code intercepts, redirects, and retires old code one component at a time, so you never need a code freeze, and you never have a migration weekend.

In a low-code context, that means standing up Postgres and a Django or Node service, routing one bounded capability at a time out of Bubble or Retool, and leaving everything else alone until it earns the attention.