4 ms·
I keep reading these microservice essays where the author is lost and I really feel their pain. In that spirit, let me try to make things as simple as possible.
by DanielBMarkham 4y ago
I keep reading these microservice essays where the author is lost and I really feel their pain. In that spirit, let me try to make things as simple as possible.
(True) Microservices have no dependencies on anything but unstructured text data. They do not couple to a database, the business understanding of what it's doing, a domain model, or anything else. They perform a simple, idempotent, business task that can never fail although it can create various error chains.
Programming at scale is tough. There's no free ride here. All you've done is turn the traditional model of coding "inside-out" and now you've got a ton of work doing all of the wiring.
But if you keep your microservice doing one simple useful business thing, then all of that inside-out work become business decisions. What do we do if the sign-up fails? How do we move IMPORTANT-THING to those other guys to use? You still have business coupling: things change and you have to adapt. But you're not coupled at the _coding_ level. If there's any magic, that's it. Your business should be able to wander all over the place and your microservices hold up just fine. The old way, where we may have coupled every little business need or want with every piece of code in the system, was not only a pain, more importantly it was impossible to keep organized in any one person's head and aligned with everyone else at scale.
What I see is a lot of drift. Folks start coupling things up, perhaps by trying to create one domain model to rule them all. They start creating microservices to do _system_ activities, like flushing a cache. There should be a one-to-one correspondence between your microservices and interesting business conversations. That's a hella discipline to maintain. It may force a lot of conversations you thought you could avoid by hiding them in a class hierarchy somewhere. Once you start drifting, pretty soon you're writing essays like this. And then here we are/
- XCabbage 4y agoThis doesn't make much sense. "Interesting business conversations" should map 1-to-1 with microservices but also each microservice must perform a "simple, idempotent business task" but also microservices can't be coupled to a database? Okay, enjoy developing your business with no data persistence whatsoever and where your architectural principles forbid you from ever so much as sending an email.