This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries.
What Even Are Microservices?
11–20 of 87 posts
Re: What Even Are Microservices?
#12Compare the fuel pump of a Jumbojet and of a car. Is the smaller one a micro-pump? No, they are both pumps. Any "micro service" is just a service. Ref: Juval Löwy
Re: What Even Are Microservices?
#13Something people use to architect towards being the next Amazon, before they've even got their first 100 users. Also useful for CV padding.
Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.
Re: What Even Are Microservices?
#14Conway's Law at the boxen level?
Re: What Even Are Microservices?
#15I decided to take a career break and build an open source project to manage services better. Feedbacks are welcome, product is too early for adoption.
https://github.com/GoPlasmatic/Orion
Design principles: * Isolate business logic from service framework using declarative coding * Make the logic representation machine-writable so AI is a first-class author * Treat business logic as versioned data, not compiled services * Ship governance with the platform, not with each service * Invoke services in-process, not over the network * Modular monolith — export and scale a service independently when needed * Push integrations into declarative connectors, keep logic pure
Re: What Even Are Microservices?
#16> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…
I think you described not monolith vs microservices, but single person working on a project and making decisions vs multiple. “Everyone’s responsibility is no-one’s responsibility” works the same way if multiple people work on the same microservice.
Also a monolith may (actually, must) have internal public interfaces through which components must communicate, and those contracts are more enforceable, amenable to static checks, and much higher performance that microservices’ network interfaces.
Re: What Even Are Microservices?
#17Or get the best of both worlds, use a monorepo with microservices.
Re: What Even Are Microservices?
#18> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…
This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.
Re: What Even Are Microservices?
#19> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…
> I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is.
Then they can retrieve it from source control? Leaving dead code in the codebase because "someone else might want it" sounds like nonsense.
Re: What Even Are Microservices?
#20> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…
I think you described not monolith vs microservices, but single person working on a project and making decisions vs multiple. “Everyone’s responsibility is no-one’s responsibility” works the same way if multiple people work on the same microservice. Also a monolith may (actually, must) have internal public interfaces through which components must communicate, and those contracts are more enforceable, amenable to stat…
monoliths can be anything under the boundaries. That's why people get this so wrong. There is no rule that says you must have internal public interfaces (misnomer? how can it be public, but internal, at the same time?). Microservices were entirely designed to split work across teams.