The best point u spoke about was for startups microservices can be expensive but if you start with building each function with well defined interface it will be easy to migrate to microservices easily.. that totally makes sense :)
@@princezuko7073 if we use interfaces for each of the domains in the example like for cart, billing, users etc. It'll be easier to shift them to a microservice since each one is independently written.
@@princezuko7073 Interfaces can be used internally between the same system, vs only using them for external communications. Implementing them during initial design means that if you want to swap to microservices, the interfaces already exist and it makes it managable to migrate over (else you would likely be re-writing/refactoring basically the whole app).
@@benhook1013 And regardless, having well interfaced functions makes code easier to test using mocking libraries, rather than having highly coupled code which is impossible to properly test
Generally small and mid size app can be easily developed with monolith with great scale sometime we over engineer things for fashion like microservices
@@nishithonshorebackup7446 Develop your app faster. Find out sooner if it makes money. After that you can hire more people and change the architecture. But if you know its scale beforehand and choose microservice architecture then it's not future proofing.
I've watched numerous videos in an attempt to comprehend this architecture, and I've finally come across the absolute best one. Thank you so much for sharing it; it's truly amazing!
This is a great video, the only thing I would have added is that microservices are most applicable when your teams, and the business, are structured in a way that needs separate development and release timelines. If that isn't the case, the disadvantages outweigh the advantages 9/10 times, as large services perform better, are easier to develop and secure, and cost less .
What about when you move to serverless architectures where you pay for what you use and split your app into long running and short running functions? I ask because we’re doing a transformation and currently we deploy a monolithic app to a kubeneties cluster so we’re paying a constant fee to have resource’s running all the time, I would have thought moving this to lamda for all sub 10-15 minute tasks which is probably 80-90% of all tasks mean we pay fractions of a penny on an event and then any long running we move to step functions where we can or some docker container running on a smaller amount of fixed resources? Just wondering is all because I thought paying for fixed resources is more expensive than paying for time on resources?
@@buddinghero That depends on if you actually can use fewer resources to run the remaining 10-20% of services. If you still need the same number of machines of the same size to run those 10-20% of remaining tasks, then it'd be largely a waste of time to separate out lambda functions, and you now also suffer performance additional deployment pipeline overheads for no/little gain. Monoliths are typically quite efficient for resource usage (RAM, CPU, network bandwidth etc.) as you don't have additional overheads of separate running operating systems/process domains. A big downside of Monoliths primarily being you have to deploy the whole unit every time stuff changes and depending on the language the compile time might be a significant overhead too.
@@buddinghero If your services are used infrequently, serverless computing makes sense. But serverless is limited. Each cloud provider has their own serverless system so you are locked into a vendor. I normally use AWS. A request has to be processed within 5 seconds default timeout. It also has memory limit. To expose it to web, we have to use AppGateway, which is expensive and has its own way of deployment(dev/qa/prod). Sometimes I want service other than simple request/response like WebSocket, Cron, Subscription to MQ. Although AWS lambda sort of provide those functionality, I feels more natural to just set up a box. There are other obvious issues like cold start, no local state(no keep-alive, no internal cache, no connection pool), price(expensive when directly compared to ec2 or onprem server), deployment(need to deploy each function).
Thank you for making this video! It’s incredibly clear and concise and I feel it will help my team and my work! Please please keep up the great work, I’ve really appreciated the two videos I’ve stumbled across of yours and I’ll be watching more of your content over the coming days/weeks/months! Brilliant content, you should be proud! ☺️☺️
Independent deployability of microservices is probably their biggest advantage because it leads large organizations to faster time-to-market while limiting the blast radius of new deployments. Besides, independent scalability of microservices over monoliths is a very crucial advantage which helps them adapt easily to the increasing workload.
Add the data duplication between microservices, to have full resiliency. This topic is always overlooked, provide this data duplication layer using event streaming processing and mid devs will have the full picture. Amaizing explanation
You can keep the foriegn keys, all you need to do is also have that table with only the information that it needs, this can be past from the source of truths service. E.g. if I create a new user, that source of truth service, will store the data and then publish a success message with the same data. This is so that another service can pick it up and store that same data, allowing the foriegn key. So if the users service goes down that other service still has that data, meaning it is fully functional.
The 2 words micro and services are after some time deceiving. People start confusing application with service, component with service, funtion with service. Services need model beneath them. The moment one moves data integrity into services themselves, then its time you know you exaggerated with adopting the 2 words micro and services into your architecture. Thanks for pointing out into the data integrity thing. Well done
Great videos. We like to have a "multi-services" architecture where size is more of a deployment detail, thanks to Kubernetes. Also, most important in cloud architecture is to be event-based from the start to avoid Web-Of-Hell service architecture.
RPC: It’s like GPRC to provider faster response, but blast radius or impact to other micro-service would be larger when the service was go down. Event Streaming: It provides better isolation between services but they take longer to process. What about message brokers ?
Question, if any one can answer : Where does the Integration Layer (Eg. connecting to some Core Banking), fit in ? The explaination suits well for previously done web applications and breaking them into MS. How about cases like IIB / Mule / WSO2 Micro Integrators etc, where services are built for transformations etc. Do they also fit-in to this description ? Appreciated !
I really like your videos! cheers!!!! If you like the idea, could you make some videos about IT careers? Like the responsabilities of each job and how do they relate in a big size company? (like spotify or amazon) tyvm anyway!
Nice explanation Sir , make me completely understand between monolithic architecture ( I still use these days , since the very small organization - less than 9 people ) , Three tier architecture ( that my clients use these days ) and Microservices architecture ( I never use and still learning ) .
I'm infatuated with this. I recently enjoyed a similar book, and I was truly infatuated with it. "Mastering AWS: A Software Engineers Guide" by Nathan Vale
Great video and very clear explanation! I would like to suggest a video with more detailed explanations about DDD and how to scale SQL and non-SQL databases. Please, what set of tools do you use to build your presentations / videos?
Almost nothing mentioned in this video is specific to microservices. Well-isolated domains with clean interfaces, small surface areas, scaling of different parts of the system, separated databases, api gateways; monoliths do these things too. Independent deployment is the only area where microservices differ, and it's not necessarily an advantage. It depends greatly on your specific circumstances. I think part of the problem is many people didn't learn about these concepts until microservices came along, and so they mistakenly conflate things. The reality is these ideas have been promoted in software development for a long time. They just didn't gain traction until more recently.
interesting, do you see any value in applying the design patterns of object oriented system design into microservices ? the fundamentals look somewhat similar. What are your thoughts on complex orchestration tools?
I feel like this is a "is a hotdog a sandwich" style of argument. If your domains inside of a monolith are completely isolated, talk to each other over http or through event brokers, and all have their own databases, can that really be called a monolith? This is a vast minority of monoliths, probably less than .1%.
@@cyropox8235 If the deployments of the various components are interdependent then yes, it’s still a monolith. If the pieces live and die together, whether by design or by consequence, it’s a monolith. The key characteristic of microservices is the lack of deployment-time dependency. A may call upon B which calls upon C, but that doesn’t mean they have to share an existence. It doesn’t mean they have to be deployed together or in a particular sequence. They’re free to come and go without taking down anyone else. Sure, A might not be able to fully do its job without B, but it won’t crash. It won’t fail to come online if deployed first, and it’ll happily sync up once B does appear. Put another way, microservices strive to eliminate any technical need to deploy things in a certain fashion. They allow such decisions to be made for business reasons, such as presenting a certain experience or handling variable customer load.
I would say the scaling of monolith is totally different to a scaling of a microservice. Every component in a monolith has to share the device resources (CPU, memory and network bandwidth) with each other, whereas each microservice can run on a totally different device. Now if you're going to go out and say you host multiple 'stripped-down' versions of your monolith on different devices, then it's not really a monolith at that point. It's just a messy microservice.
@@DynamicalisBlue A monolith is certainly more limited in how far it can scale because everything is constrained to a single node, but it still can scale. That is not something specific to microservices. Also, not every distributed application is necessarily using microservices. It's not enough to just break things up into separate processes on different nodes.
I'd add you need to consider failure domains when discussing MS isolation. E.g. if all your databases are hosted on one DB cluster and that cluster goes down - these's not much isolation. All your services can't work
As Zolando CTO says 7 years ago "There was _no_ technical reasons to moving from monolith to microservices. The only one reason is people don't like to write code in Java, people want to try many other languages. And only microservices makes possible to retain and hire more people."
I think it's the matter of cloud service marketing to hype the microservices, and then their tools will be make sense and they start making money. Nothing wrong with moonlit as long as you know how to scale up that, heck can you imagine if SAP breaking down to microservices.
RPC: It’s like GPRC to provider faster response, but blast radius or impact to other micro-service would be larger when the service was go down. Event Streaming: It provides better isolation between services but they take longer to process. Does anyone know why event streaming take longer ah?
AFAIK, you can create gRPC methods as request/response or streaming. If you have to send a lot of data, request/response is the faster way to send data. I think event streaming is slower because queue is involved between server and client.
A question I have is why do we call such architecture as MICRO services ? I can see that we are breaking a large application into loosely coupled services - which are themselves applications in their own right, but why are we saying they are micro ? Or is it just a nomenclature that was born as such ? Many thanks. A
What tool/software do you use to make your animated graphics? Like the animated graphic at :23 seconds into the video, for example.. Love all your videos, by the way! You have a great ability to convey information clearly and concisely.
I am guessing he uses a tool like Manim, which is a Math Animation library written in Python by Grant Sanderson, who posts content as 3Blue1Brown. I've experimented with the library. It is well done but poses a bit of a learning curve for those new to Python.
Thank you very much for the video. Just a quick question - The communication between microservices using event streaming, does it take long time to process with traditional streaming solution? I was just looking at Kinesis Data Stream and can provide milliseconds.
Thank you for making this video! And i have question what software do you use to create tech videos like this? It's really creative in terms of visuals
By "well-defined interface" do you mean Microframeworks? Thank you for your animated illustrations, it really helps a lot to help me understand the complexity of this method.
The best point u spoke about was for startups microservices can be expensive but if you start with building each function with well defined interface it will be easy to migrate to microservices easily.. that totally makes sense :)
Sorry but Can you explain this a bit? “Building each function with we defined interface” - what it means? I couldn’t understand.
@@princezuko7073 if we use interfaces for each of the domains in the example like for cart, billing, users etc. It'll be easier to shift them to a microservice since each one is independently written.
@@princezuko7073 Interfaces can be used internally between the same system, vs only using them for external communications. Implementing them during initial design means that if you want to swap to microservices, the interfaces already exist and it makes it managable to migrate over (else you would likely be re-writing/refactoring basically the whole app).
@@benhook1013 And regardless, having well interfaced functions makes code easier to test using mocking libraries, rather than having highly coupled code which is impossible to properly test
@@saikrupacharyarendra850 thanks for explaining it @sai
Generally small and mid size app can be easily developed with monolith with great scale sometime we over engineer things for fashion like microservices
What is small today may be large tomorrow. What you think as over engineering may be a future proof design. Just a thought 🙂
@@nishithonshorebackup7446 Develop your app faster. Find out sooner if it makes money. After that you can hire more people and change the architecture.
But if you know its scale beforehand and choose microservice architecture then it's not future proofing.
A good example is stackoverflow, it's a monolith running on on-prem servers
@@nishithonshorebackup7446 or maybe it is just over engineering and premature optimization because your app may never get the attraction you wanted
@@nishithonshorebackup7446 future proofing is an anti pattern, you can not possibly foresee all future problems you will have with your codebase.
I've watched numerous videos in an attempt to comprehend this architecture, and I've finally come across the absolute best one. Thank you so much for sharing it; it's truly amazing!
I second that! Been through a couple of videos and this one is the most comprehensive one!
what a great explanations and phenomenal graphics - not distracting, clear, direct! gold!
This is a great video, the only thing I would have added is that microservices are most applicable when your teams, and the business, are structured in a way that needs separate development and release timelines. If that isn't the case, the disadvantages outweigh the advantages 9/10 times, as large services perform better, are easier to develop and secure, and cost less .
What about when you move to serverless architectures where you pay for what you use and split your app into long running and short running functions? I ask because we’re doing a transformation and currently we deploy a monolithic app to a kubeneties cluster so we’re paying a constant fee to have resource’s running all the time, I would have thought moving this to lamda for all sub 10-15 minute tasks which is probably 80-90% of all tasks mean we pay fractions of a penny on an event and then any long running we move to step functions where we can or some docker container running on a smaller amount of fixed resources? Just wondering is all because I thought paying for fixed resources is more expensive than paying for time on resources?
@@buddinghero That depends on if you actually can use fewer resources to run the remaining 10-20% of services. If you still need the same number of machines of the same size to run those 10-20% of remaining tasks, then it'd be largely a waste of time to separate out lambda functions, and you now also suffer performance additional deployment pipeline overheads for no/little gain.
Monoliths are typically quite efficient for resource usage (RAM, CPU, network bandwidth etc.) as you don't have additional overheads of separate running operating systems/process domains. A big downside of Monoliths primarily being you have to deploy the whole unit every time stuff changes and depending on the language the compile time might be a significant overhead too.
@@buddinghero If your services are used infrequently, serverless computing makes sense. But serverless is limited. Each cloud provider has their own serverless system so you are locked into a vendor. I normally use AWS. A request has to be processed within 5 seconds default timeout. It also has memory limit. To expose it to web, we have to use AppGateway, which is expensive and has its own way of deployment(dev/qa/prod). Sometimes I want service other than simple request/response like WebSocket, Cron, Subscription to MQ. Although AWS lambda sort of provide those functionality, I feels more natural to just set up a box. There are other obvious issues like cold start, no local state(no keep-alive, no internal cache, no connection pool), price(expensive when directly compared to ec2 or onprem server), deployment(need to deploy each function).
I've seen many of your videos and this one made me subscribe to your channel... Extremely clear explanation of such a complex topic. Keep up!
Welcome aboard!
"BLAST AREA" great selection of words
Thank you for making this video! It’s incredibly clear and concise and I feel it will help my team and my work! Please please keep up the great work, I’ve really appreciated the two videos I’ve stumbled across of yours and I’ll be watching more of your content over the coming days/weeks/months! Brilliant content, you should be proud! ☺️☺️
This is literally the best advice around microservices i've heard!
I usually don’t subscribe any youtube channel but this one make my finger to click the button subscribe! Thank you. This is very easy to understand
Your videos are excellent!! Can you do one like this on grpc vs REST APIs?
In 4 minutes you ve given a ton of heavy info, thank you !
Independent deployability of microservices is probably their biggest advantage because it leads large organizations to faster time-to-market while limiting the blast radius of new deployments. Besides, independent scalability of microservices over monoliths is a very crucial advantage which helps them adapt easily to the increasing workload.
Add the data duplication between microservices, to have full resiliency. This topic is always overlooked, provide this data duplication layer using event streaming processing and mid devs will have the full picture. Amaizing explanation
The first video I struck by and paused to subscribe the channel, thank you!
Knowing your channel is my gift today,thank you for your Brilliant content
Thank you for making these great videos. They've helped me a lot. You're a great artist and teacher. I look forward to all your media and information.
Very helpful video! Explained very well, and easy to understand. Thank you, Sir!
I use microservices since 2000. I am confident - it is a cool technology.
learnt a lot in those 5 minutes. ud have loved to know more about "blast radius"
I am preparing interview now, this is perfect to sum up the concept! Two thumbs up! Subscribed!
the best video explainer ive seen so far. Thanks
This was well put. Short and very helpful.
one of the best explanation available on youtube
Lovely visual illustration, great accompaniment to technicals in the presentation
Great video and clear explanation! Could you make a video on the comparison of spring cloud and kubernetes?
As usual, awsome presentation - Wish for more!
You can keep the foriegn keys, all you need to do is also have that table with only the information that it needs, this can be past from the source of truths service. E.g. if I create a new user, that source of truth service, will store the data and then publish a success message with the same data. This is so that another service can pick it up and store that same data, allowing the foriegn key. So if the users service goes down that other service still has that data, meaning it is fully functional.
The 2 words micro and services are after some time deceiving.
People start confusing application with service, component with service, funtion with service.
Services need model beneath them.
The moment one moves data integrity into services themselves, then its time you know you exaggerated with adopting the 2 words micro and services into your architecture.
Thanks for pointing out into the data integrity thing. Well done
Great videos. We like to have a "multi-services" architecture where size is more of a deployment detail, thanks to Kubernetes.
Also, most important in cloud architecture is to be event-based from the start to avoid Web-Of-Hell service architecture.
RPC: It’s like GPRC to provider faster response, but blast radius or impact to other micro-service would be larger when the service was go down.
Event Streaming: It provides better isolation between services but they take longer to process.
What about message brokers ?
This was a wonderful tutorial of micro services vs monolithic architectures! Thank you for paving the way!
This channel is treasure!
Thanks for sharing this info. I have a doubt we have only 1 shared API gateway, what if it goes down?
Can u pls discuss how Authentication and Authorization is implemented in Payment systems?
Clear explanation. Thank you so much for your video. It helped me a lot.
Question, if any one can answer :
Where does the Integration Layer (Eg. connecting to some Core Banking), fit in ? The explaination suits well for previously done web applications and breaking them into MS. How about cases like IIB / Mule / WSO2 Micro Integrators etc, where services are built for transformations etc. Do they also fit-in to this description ?
Appreciated !
I really like your videos!
cheers!!!!
If you like the idea, could you make some videos about IT careers? Like the responsabilities of each job and how do they relate in a big size company? (like spotify or amazon)
tyvm anyway!
Hi,
Your videos are very informative & easy to understand.
Can you make videos on various design patterns of micro service
Thanks buddy,
As always I hit like first async watch and rewatch await finally comment
Outstanding Video! Well explained. Thanks!!!
that was brilliant explaination!
Thanks alot!
your matherial is the best on the internet, keep doing it
Insightful, thanks for breaking this down.
Great video! Would the additional communication overhead between more micro-services a downside of this architecture?
Nice explanation Sir , make me completely understand between monolithic architecture ( I still use these days , since the very small organization - less than 9 people ) , Three tier architecture ( that my clients use these days ) and Microservices architecture ( I never use and still learning ) .
Duuuude, that prez is awesome 🤩
Thank for awesome explanation. Also if possible add realtime project
nice, short and clear. thank you for the video.
Microservices are actually really easy to implement and deploy with something like Railway
Really high quality material, thanks for sharing Alex! 👏
I'm infatuated with this. I recently enjoyed a similar book, and I was truly infatuated with it. "Mastering AWS: A Software Engineers Guide" by Nathan Vale
Great video and very clear explanation!
I would like to suggest a video with more detailed explanations about DDD and how to scale SQL and non-SQL databases.
Please, what set of tools do you use to build your presentations / videos?
Absolutely Perfect, thank you.
Very good explanation. Well presented. Thanks for sharing this video.
Almost nothing mentioned in this video is specific to microservices. Well-isolated domains with clean interfaces, small surface areas, scaling of different parts of the system, separated databases, api gateways; monoliths do these things too. Independent deployment is the only area where microservices differ, and it's not necessarily an advantage. It depends greatly on your specific circumstances.
I think part of the problem is many people didn't learn about these concepts until microservices came along, and so they mistakenly conflate things. The reality is these ideas have been promoted in software development for a long time. They just didn't gain traction until more recently.
interesting, do you see any value in applying the design patterns of object oriented system design into microservices ? the fundamentals look somewhat similar. What are your thoughts on complex orchestration tools?
I feel like this is a "is a hotdog a sandwich" style of argument. If your domains inside of a monolith are completely isolated, talk to each other over http or through event brokers, and all have their own databases, can that really be called a monolith? This is a vast minority of monoliths, probably less than .1%.
@@cyropox8235 If the deployments of the various components are interdependent then yes, it’s still a monolith. If the pieces live and die together, whether by design or by consequence, it’s a monolith.
The key characteristic of microservices is the lack of deployment-time dependency. A may call upon B which calls upon C, but that doesn’t mean they have to share an existence. It doesn’t mean they have to be deployed together or in a particular sequence. They’re free to come and go without taking down anyone else. Sure, A might not be able to fully do its job without B, but it won’t crash. It won’t fail to come online if deployed first, and it’ll happily sync up once B does appear.
Put another way, microservices strive to eliminate any technical need to deploy things in a certain fashion. They allow such decisions to be made for business reasons, such as presenting a certain experience or handling variable customer load.
I would say the scaling of monolith is totally different to a scaling of a microservice. Every component in a monolith has to share the device resources (CPU, memory and network bandwidth) with each other, whereas each microservice can run on a totally different device.
Now if you're going to go out and say you host multiple 'stripped-down' versions of your monolith on different devices, then it's not really a monolith at that point. It's just a messy microservice.
@@DynamicalisBlue A monolith is certainly more limited in how far it can scale because everything is constrained to a single node, but it still can scale. That is not something specific to microservices.
Also, not every distributed application is necessarily using microservices. It's not enough to just break things up into separate processes on different nodes.
Illustrations / animations are awesome. Great work 👏🏻 May I know which tool you use ?
Our talented editors use Adobe Illustrator and Adobe After Effects.
This is just amazing! Good job explaining!
Appreciate the very good explanation and illustration ⭐⭐⭐⭐⭐
I'd add you need to consider failure domains when discussing MS isolation. E.g. if all your databases are hosted on one DB cluster and that cluster goes down - these's not much isolation. All your services can't work
Awesome explanation as usual, thank a lot
Love all your videos!
As Zolando CTO says 7 years ago "There was _no_ technical reasons to moving from monolith to microservices. The only one reason is people don't like to write code in Java, people want to try many other languages. And only microservices makes possible to retain and hire more people."
I guess you meant "Zalando", right?
Maybe there wasn't for them. Maybe their app wasn't big enough
I think it's the matter of cloud service marketing to hype the microservices, and then their tools will be make sense and they start making money. Nothing wrong with moonlit as long as you know how to scale up that, heck can you imagine if SAP breaking down to microservices.
Why i should care what Zolando CTO says? What you have done here is just a appeal to authority fallacy.
RPC: It’s like GPRC to provider faster response, but blast radius or impact to other micro-service would be larger when the service was go down.
Event Streaming: It provides better isolation between services but they take longer to process.
Does anyone know why event streaming take longer ah?
AFAIK, you can create gRPC methods as request/response or streaming. If you have to send a lot of data, request/response is the faster way to send data. I think event streaming is slower because queue is involved between server and client.
Great videos, I love to see how much have you improved your content. What are you using to create such as amazing animations in those diagrams?
I am also curious to know!!
These are great thank you! More please!
A question I have is why do we call such architecture as MICRO services ? I can see that we are breaking a large application into loosely coupled services - which are themselves applications in their own right, but why are we saying they are micro ? Or is it just a nomenclature that was born as such ? Many thanks. A
I love the whole video and animation as well. Could you please tell me how you created or what you used for it.
Hello, can you explain how push notifications works?
Excellent video and deeply explained
very nice and straight to the point video, thx a lot man.
Thank you very much for this great content
What tool/software do you use to make your animated graphics? Like the animated graphic at :23 seconds into the video, for example.. Love all your videos, by the way! You have a great ability to convey information clearly and concisely.
I am guessing he uses a tool like Manim, which is a Math Animation library written in Python by Grant Sanderson, who posts content as 3Blue1Brown. I've experimented with the library. It is well done but poses a bit of a learning curve for those new to Python.
In another video he said his team uses Adobe After Effects and Adobe Illustrator.
@@stratfanstl does not look like manim, besides manim is mainly targeted at math-related animations anyway
@@MouliSankarS Both After Effects and Illustrator are paid. It looks like all products of Adobe are only available in paid versions.
Our talented editors use Adobe Illustrator and Adobe After Effects.
Microservices is dealing with complexity with complexity, similar to fighting fire with fire (which is how it is done for big fires).
i love this chanel, make every thing easy know
Thank you very much for the video. Just a quick question - The communication between microservices using event streaming, does it take long time to process with traditional streaming solution? I was just looking at Kinesis Data Stream and can provide milliseconds.
Excellent series. Which software you used to make these animated flowgraphs? I am a teacher making course. How you move bits and packets?
short and clear. thanks!
What do you use to make these diagrams and animations?
+1
.
Illustrator, After Effect. In another video comment section he said that. And also, a team and person in front of the monitor is the key.
@@cutiaja oh, wow. You actually know that humans make things. How wise. How rare.
@@gritcrit4385 Thanks. I am wise. Just realize it. 😂. The Mr. Wise.
Thanks for the great video. I was also wondering what software did you use when you were creating the visuals for the video because I liked it a lot?
@ByteByteGo, Sir your designs are really cool. If possible can you please suggest which software you are using to draw these.
Solid good stuff, thank you!
This was a very good video explaining microservices!
Perfect as always.
As with all other videos - a great one, thanks!
a video on soa would be greate
Thank you for making this video! And i have question what software do you use to create tech videos like this? It's really creative in terms of visuals
Can you do a video on When to use GraphQL
By "well-defined interface" do you mean Microframeworks? Thank you for your animated illustrations, it really helps a lot to help me understand the complexity of this method.
Great video, thanks !
Insightful!
thank you.
very informative video, thanks!
Great video thank you!
thanks for yours pearls of wisdoms
Aforementioned 3 ways of microservice to communicate with each other, What's the difference between msg broker and event stream?
Used. Thank you
Thank you great explanation
Can you make a video on micro-front-ends?
Hi, you and your content is awsome. what tool you are using for animation and art design
Gap yuq lekin bro omad