Of course, a 12F app is just one way you could build a microservice and other strategies are viable (and don’t make you any less a microservice as long as you don’t violate the principles).
Comments
Log in with your Bluesky account to leave a comment
Thanks Ian. Completely agree with "Micro services belong in the development view". Describes what I'm trying to say in a much better way.
I am somewhat with others who I've heard say "micro" is probably a misleading term. "Service" or "Logic Responsibility/Boundary" is probably more appropriate?
I think the "micro" tends to skew bias towards people thinking it means "single process" when really (as you allude to with your database comment) it probably means "small-ish, cohesive, autonomous, logical service" (or whatever descriptor fits the last bit).
It's an argument I've had many times, mainly with DevOps at our org who enforce a "one process per repo" rule. Which makes their work easier, but ours as architects/devs often much harder. And can lead to slow down, and a drop in quality. Or services which can't scales their workloads, separately.
I do have a talk about this: Microservices, Where Did It All Go Wrong but not sure any of the conferences have put the video out yet. I will be giving it at NDC London next week.
Comments
I am somewhat with others who I've heard say "micro" is probably a misleading term. "Service" or "Logic Responsibility/Boundary" is probably more appropriate?
It’s ironic, given their focus on cloud native, which is essentially using containers to support a 12-factor app approach.