What Kind Of Software Architecture Is This? Monolith or Microservices?
Вставка
- Опубліковано 27 лют 2024
- Can you guess the software architecture in these diagrams? What characteristics determine which type of software architecture is being used?
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via UA-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo... - Наука та технологія
This is a fun one.
It was a monolith (the good kind), then when sales service got extracted it's turned into a microservice, and when sales service had to RPC to the original service it's a distributed monolith (the bad kind, where independent deployments may break APIs).
whether the message broker's shared or the database instance (but not the schema) is shared is irrelevant to this characterization.
It's a modular monolith transitioning to a service-based architecture, due to scaling requirements.
It's definitely not microservices, because there is nothing "micro" about packaging the entire domain in a service.
Also, service-based allows you to share monolithical data but also to partition it, when possible.
Check out the lessons from Mark Richards on the topic. Seems to fit the bill pretty well.
I would call the first architecture a distributed monolith. There is coupling between the boundaries, they share a single DB, which makes them a monolith. On the physical side, it's deployed as several processes, and that makes it a distributed monolith.
Thank you, thank you, thank you! Finally someone says, architecture style is not solely defined by how you deploy your code, or where it lives in a repository! 🎉🎉🎉.
Logical components can physically exist in the same process or not what a concept. One challenge I think some people run into is how to have multiple logical components communicate in a decoupled manner in an in process situation.
Sometimes in process events/callbacks are used, other times orchestration can be used, and in front end applications like web/mobile UI composition can be used.
Great topic, great video! I look forward to reading all the comments.
First one is a service oriented architecture. Separated processes using a single database.
Vertical Slice Architecture, with Microservices behavior, apparently I see that they have independently deployable behavior, this is a typical feature of Microservices, but also you can see that the modules are grouped by features that are managed independently, this is the vertical slice architecture, its a common guidance from a lot of your videos. You really explain it to us so well
Well Derek, I think this is kinda funny because I asked about this on Discord not too long ago. My assumption at the time was "Hey the two services are related, but still 'independently' deployable, even thought they share the same database. So still microservices right, because part of the same logical boundary?"
I think your response was something like they don't really fit the definition of what you may call a "service." Because it's two independently deployable things share the same db, no matter how related they may be in "purpose" or overall behavior of the system. So yeah, probably distributed monolith-y type thing.
Architecture is about what characteristics you want your system to have. Since how you deploy affects the characteristics of the system (e.g. everything in a single process vs multiple processes so you can scale differently), then architecture is about what physical boundaries you define among the components of your system.
1. distributed monolith if they depend on each other directly
i imagine microservices as completely independent services that can scale up and down according to some loadbalanced/message queue based demand. by independent I mean that scaling that microservice does not require scaling "other" microservices. It is hard to define when a microservice is no longer a microservice as it is situational.
if the boundary requires scaling other microservices alongside it, why are they separate? to me this logic only starts to break down when the microservice does literally 1 thing like sending emails and several other services count on it, but then it has a very singular focus and is an actual micro service.
day to day i don't discuss whether it is a microservice, monolith, or something else entirely. it is all about solving the problem the right way.
I'd agree, so far.
But it depends on what is in the shared DB.
If every of these components only consumes their own tables in the DB, using a single DB is not a big problem.
If the DB is kind of hidden interface between different components, well in that case it's a distributed monolith for sure. 🙂
@@josefpharma4714 agree to an extent, but it is not completely black and white to me. you can do an initial expansion from 1 process to 2 processes using the db alone with a setup that is as decoupled as a message broker (e.g. json columns or whatever you can think of). it is a good starting point sometimes for splitting services.
Coupling can be minimised, but can never be ZERO.
An architecture with minimal coupling promotes independent deployment of the modules.
Reducing coupling is the key, no matter if it is monolith or microservices
Huzzah!
It's a distributed monolith, since you never mentioned versioning of events in the broker.
Hi, in future can you make a video about state implemetation and state transition with rules, some people say that state machine is not the best solution to do this and using switch/case isn't a good practice
This? ua-cam.com/video/q07FkWjtbAY/v-deo.html&lc=UgzKFdEhfmSnFnXDxY94AaABAg
I really think about this in the same way for more than 20 years - really! The big problem is, how can we keep all deployment possibilities without complicating our code unneccessarily? Take for example the framework extension Spring Modulith: It helps you to build up a clean Modulith. But it doesn't help you to make a bunch of microservices out of it later. The truth is: We must decide if we go for some simplicitiy regarding application contexts, transactions, pools, connections, messaging - if we only want a modulith. But if we maybe want microservices later, we have to care about a lot of complications from the beginning - because we should design our building blocks and their in-between communcations in a way that allows us to tear them apart.
Microservices is about deploying services separately - and you can deploy that from a monorepo - I do. It just adds some complexity. Likewise, you can split something into separate repositories, but still requiring them to get deployed together - which is a monolith. That was what "microservices" as a buzzword was about taking into consideration and avoiding if possible. But few seem to have understood that. And now with DDD and boundaries into the mix.
In a monorepo how do you prevent unwanted coupling to 'shared' projects.
Do you ever do mob programming sessions? That would be amazing to be a part of in terms of practically exploring your opinions and approach in real time
Excellent! All I can do is drool into my chin bucket, for I am but a idiot at this level of architecture. I am a low-level guy, pixels, bits, electrons, VHDL and 5 or 3.3 volts all the way. But I would like to understand these higher level things, the tradeoffs to be made, the concepts, useful categories. So many YT videos describe, show, tell, but this video is unique in making a quiz out of the topic. I like that! Despite me, a caveman, being capable only of dragging my hairy knuckles along the ground regarding this topic, I am a fan.
Thanks for the feedback. It's a bit different but same thread as most of my videos. I didn't think of it as a quiz but it kinda is!
I don't understand this craziness about mono-repo and, even, they idea that starting with microservices is wrong.
In Visual Studio, we load a shared chassis in our solutions that we all contribute to.
Setting up a new solution becomes trivial. Projects look extremely clean.
Micro-services, not only bring resiliency, it also opens up a whole world of opportunities with no impediments.
Ownership and collaboration are key factors.
I would say modular monolith for the first, then SOA for the second. I thought microservices where more granular than a sales service ??
According to Robert Martin Uncle Bob "microservices architecture" is not architecture at all, it is just a deployment model. And it's not new thing, it's rather old. Anyone remembers IPC through shared memory in Linux? Isn't it "microservices"? :)
7:35 yes. because now you have a distributed system in your "backend"
One logical boundry could be made of multiple apps that are deployable and scalable toghether idependently of the rest of the system. Rigth?
At 4 minutes in, it looks like a distributed monolith to me.
Hi Derek, Is the mailing list active ? I've never received a single mail from it :(
SOA
3:58 so far I'd call a modular monolith
Citadel architecture
Well. I dunno. But is it easy to work with? Great!
Monolith of mud? :)
It is a Solution Architecture 😉
If you are using the same database you are in Modular monolith land, if you split the databases you are now doing microservices
absolutely not
Yep, coupling is the key. It is what brings you the distributed monolith. The bane of all system designs. Worst of all worlds.