Story: architecture experiment

I was working in a new project that had a microservice architecture at TomTom since January.

I was enrolled in the Course: Cloud Native Entrepreneur - Patrick Lee Scott since December. In this course he teaches about cloud native (microservices and devops) and entrepreneurship.

I was thinking about solving my problem of better highlighting / note-taking while reading.

I enrolled in the Course: Advanced Distributed System Design - Udi Dahan where I picked up the idea that deciding which things are deployed on the same machine can be decided later

Oh and a year I learned CQRS and eventsourcing, mainly from Greg Young's materials

So I was building an architecture experiment / pet project in a mash of these styles

TomTom project microservices
Patrick Lee Scott microservices
Udi Dahan's SOA & decouple functional and deployment model
Greg Young's eventsourcing + CQRS

I learned a lot from this architecture style experiment. And I was even able to contribute learnings from this to the project I was working on at TomTom.

I especially liked Udi's idea of deciding later which functionality runs where.

Especially combined with Patrick's microservice patterns causing tiny functional pieces and unidirectional data flow.

This allowed me to flexibly move deployment-service-boundaries.

But it did come at a cost of having to invent quite a bit of boilerplate code.

I didn't mind because I quite liked refactoring this to common libraries.

And I ended up with a lot of reusable pieces, used by multiple microservice patterns.

Okay, this is getting confusing, because the definition for (micro)service I usually use:

single unit of deployment

This get's really fuzzy when combined with

flexibly move deployment boundaries

So in my first draft of the previous paragraph, I mixed logical-(micro)service and deployment-(micro)service.

I'll write some posts about this in the future for more clarity:

The cost of running this in production was $100 per month.

Which was way too much for this pet project.

So I ended up only running it locally in a minikube.

The backend was extremely over-engineered for the problem it solved.

But that was intentional as I wanted to learn the architecture style.

More than solve I wanted to solve the problem, at that time.

Later I got more serious about the problem to be solved: "improve note taking while reading" (see Mindmark.it - the origin story)

And after a while I discovered a pivot that would provide much more valuable.

It would require me to rewrite the whole thing.

The goal now is "improved note-taking", instead of "experiment with this architecture style".

So I decided to also simplify the backend to a classic consistent monolith.

This is much simpler and matches the current complexity of the problem.

And much cheaper, which is important because this time I actually want to have a production environment so I can use it!