@thabangmotaung9637
The structure of your content delivery makes it easy for me to understand these concepts in a snap.
@Jabali04
*Summary: Monolithic vs Microservice Architectures* 1. Monolithic Architecture - All functionalities reside within a single codebase or project. - Simpler to develop and maintain initially, as it involves managing just one "component." - Internal communication is seamless, eliminating performance concerns between functionalities. - Challenges arise as the application grows: - Larger, more complex deployments. - Scaling issues: the entire application must scale, even if only one feature demands it. - Longer development and release cycles due to tightly coupled components. 2. Microservice Architecture - The application is divided into independent, smaller services, each focusing on specific functionalities. - Advantages: - Independent maintenance, development, and scalability of components. - Greater flexibility to scale individual services based on demand. - Challenges: - Increased complexity in development, testing, and debugging, especially for multi-service environments. - Difficult to simulate the entire application locally. - Higher infrastructure costs for small-scale applications. Communication Between Microservices: 1. API (Synchronous): Direct communication between components, often via REST or GraphQL. 2. Message Broker (Asynchronous): Tools like RabbitMQ enable decoupled communication by passing messages between services. 3. *Service Mesh:* Ensures service discoverability, communication reliability, and monitoring across microservices.
@ngc35ster
2:50 my company is using monolithic architecture for the backend. As Alex mentioned, it was quite sweet and swift at the very beginning. But after 8 years of code, the monolithic become a monster and now we feel the pain. (1) There are 50+ some dependencies used in our codebase, we use pipenv and it takes the resolver 10+ mins to resolve and install all the dependencies (2) We have to carefully juggle the work that will be merged into the master branch for release based on their priorities and impact. Sometimes, we have to commented out some already released feature (You read it right, we commented code out, in production release) cuz the release plan decides to postpone them.
@MaximePoulain
A topic that could be interesting to delve further into is the Modular Monolith. In contrast to microservices where the boundary is just physical, modules in a monolith are logically isolated from each other. This brings benefits like faster deployment and helps avoid issues of creating 'spaghetti code' that could cause problems for others. However, designing a modular monolith can be challenging, as it requires expertise in the design of your domain and the identification of its sub-domains (bounded context in DDD terminology) but also with the communication when an operation span accross multiple modules. Overall, I believe this approach combines the pros and cons of both monolith and microservices architectures effectively for many use cases.
@omaskery
Some things I find very confusing in discussions about microservices vs monoliths: - I don't understand why monoliths are considered problematic to scale, if a particular function is being called a lot, and other functions aren't, what is the meaningful downside? - I understand the thinking behind "instead of testing your whole application you just deploy a change to a smaller part", but in practice that's the same as changing one function's implementation inside a monolith, doesn't that mean that you have to do all the same testing again at best or - at worst - you're using microservices as an excuse not to test the entire application again? - When discussing microservice architectures nobody seems to discuss that ACID guarantees are a casualty: people generally don't utilise distributed strongly consistent transactions (e.g. 2 phase commits), and claim to be instead using eventual consistency - but from what I can see almost nobody properly implements eventual consistency (e.g. lack of outbox pattern resulting in inconsistent state & messages published). From most literature I've seen, it seems like most backend developers aren't even taught to how to ensure ACID guarantees within a single service with horizontal scaling, yet alone distributed eventually consistent systems. Most backend developers I ask about these topics just shrug, and say that they don't think about these things, and that they guess that their ORM of choice is probably handling it for them (but I'm not sure that's true!). - Microservices are often touted as being organised/divided by business functions, Domain Driven Design talks about bounded contexts, etc. The problem is that the nature of the business is constantly changing, things that used to be safely eventually consistent (and thus more easily isolated into different services) suddenly gain strongly consistent requirements. A distributed microservice codebase makes refactoring the entire system incredibly difficult. I don't see anyone discussing these things, and tutorials never seem to cover any of it. It makes me feel like I'm going insane: am I an idiot who's worrying about academic problems that don't exist, or am I an arrogant genius who tries to design for problems others don't even realise exist? Both options feel crazy or extreme! 😱
@codewitgabi
I love how you explained when to use http calls instead of message brokers for service communication. HTTP calls for synchronous requests and AMQP for asynchronous calls
@purdysanchez
Before microservices a lot of systems were just separated into normal sized services as web APIs. Microservices IMO advocated building everything with FaaS for dubious scalability reasons. Most systems weren't monoliths before the advent of microservices.
@midnightgospelll
Scaling is not an issue for Monolithic application and it's not gonna cost you fortune. Look at the Path Based Load Balancing which results in the similar flexibility when it comes to scalability for monoliths as for microservices. "When deploying one microservice, other microservices are not affected" - well, no, more often than not, they are affected
@resistance_tn
This is high quality work thank you ! Would love to see more advanced topics on networks or protocols or anything related to backed ! Keep up the great work :)
@k.alipardhan6957
why is scaling a monolith considered hard/inefficient? 3:33 if you're getting high CPU usage, just add more hosts to the cluster. isn't it that simple? it doesn't matter if 20% of code gets 80% of traffic. maybe problematic if some code is memory intensive while the highly used code is not
@liiam_9
Well structured and clear video, thanks
@trikooCreates
thank you for the swift delivery.
@elifantshoos708
Dying. The stock footage of code magically getting manifested on the scenes as the person is waving around their finger. LOL
@BenRangel
To me microservices is using ”more services than natural”. If one team of 5 devs uses many services it’s a micro service architecture. If a big company of 50 devs use 10 services it’s probably just cause they had 10 teams with one service each - so not really an intentional architecture decision
@this.channel
This was a great explanation, thanks.
@puliranjit
Love your learning videos ..well-structured , short and to the point
@xiiEJRAM
Your videos quality and the content you made are epic , I really love your channel 👌🏻
@bvreddy1074
content and delivery at it's best, Thank you so much for your time and efforts, keep inspiring and educating 😊.
@PieterWigboldus
If microservices are ride coupled, you have monolith microservices. It runs a monolith just on multiple services/processes. Microservices are very nice if you can break the most lines between the different parts, and you have the most benefit. But it takes a lot of time to learn how to do. And be aware that you dont have more microservices than active users 😊
@olter1000