There is something in between, there can be parts of your product that make sense to put in a different service. Grab the easy wins, you don’t need to call it micro services. And you definitely don’t have to put every package in its own micro service, like some people seem to think. A lot of the times micro services are just monolithic apps with added network latency 😅
The lesson is don't over engineer your projects. My projects can benefit from microservices, but it is a PITA managing distributed transactions for sure. I would also agree that going from a monolith to a soa usually ends up in a complete overhaul so it isn't really migrating, it is more starting over with a more scalable design.
I'm a junior dev. I started really getting interested into Software architecture like two weeks ago and heard about micro services. After that, I told all my friends how "good" they were (based on what I've watched and read about it) and today I had to build an API so I said to myself "lemme try this". Idek if what I did could be called microservices, but I tried to follow the concepts and after two hours, I just created another repository and build my good old monolith :). Now after watching your video I feel like a litteral potato. Guess I will send this to everyone that I've preached to about microservices XD. Thanks for the knowledge, looking for more in the future😁
I worked for a stupid company that want to use microservices with Laravel(PHP framework). They used this architecture: Laravel API Gateway -> Microservice 1 -> Microservice N. It was really SLOW in production also I don't see the point of microservices if A depends of B and always you call A you must call B. Also I think they NEVER consider the cost of that microservices, we have a Kubernetes, and about 10 diferent microservices, only for tests the company spend like 346.46 every month :/
From my point of view microservices is not all about scaling, your can scale monolith easily just like microservices. Microservices help our team develop multiple features without worry about gitflow, conflicts, all component are easy to version up, refactor or replace. So its not based on how big your system, its about how many teams are working together.
“Hey junior developer. I know you don’t know much about software development, let alone architectures and infrastructure, but you should definitely be building micro-services” - there are people who think this is a good way to go
I disagree about the monolithic codebase. The development experience depending on the project maybe great, but the deployment process can be really ugly depending on what tools you are using. I would rather build microservices and deal with their difficulty of maintaining them and etc then building a huge monolith and mainting its one big chunk.
haha, nice ending...agreed micro service strategies are more geared toward larger scale projects (we do this on my corporate side) for reusability, hot fixes, tech debt, maintenance strategies... but I feel you can start taking a reusable approach if you use techniques like duck modular approach for directory structure or developing in a "mono" structure (root directory handles the system stuff, apps directory houses the projects, packages directory houses the "micro services" such as a design system or linting configurations)...
before watching the video, my (candid) opinion: serverless event driven architectures are pretty cool:), it's okay to introduce some kind of links between services
Building an app in django and have started worrying about scaling. Rethinking microservices Lamba, API Gateway, SQS, DDB, REACT and how about mobile apps.
Great advice. And when when scaled, microservices seems like a waste. Why not think of services in general. If some of them end up being micro, that's fine.
I don't know if I agree that monoliths are flexible... But what you are describing is a distributed monolith and it's a design problem, nothing to do with micro services. Nowdays you can be more agile with microservices if you leverage cloud generic systems (serverless). You build a well sized system in a week. Authentication, comunication and scalable processing. Even robust analytics and observability
Jeez, I was on a way to build a side project and I saw this video recommend by Theo. I still wonder what would be the best architecture for small to mediums business.
It really doesn't make sense to start a brand new project with microservices as an expectation, but if the codebase is designed well, pulling out a chunk of domain into one later shouldn't be too hard. Project I'm working on now was a mono for the first two years or so of it's life, but eventually the boundaries of certain functionality became clear that it could be segregated.
People using PHP may naturally build microservices without even thinking about these issues, specially if performance is not much of an issue. A microservice is just some file in some folder that does one thing. At a small or MVP scale, it doesn't even get called very frequently, so it's fine if it's stateless and the process always has to get everything it needs for each request.
I don't agree. It is not so difficult to build microservice for a new project. But it is difficult to migrate a big monolithic (legacy) to microservice.
It's probably worth mentioning that this applies to personal projects and small startups, not the majority of software out there. If you're part of a company (such as Netflix, Uber and thousands of others) that has a culture that promotes microservices, the path of least resistance to deliver features will be through microservices.
@@jorgetirado2816 my point is for people not to get discouraged from pursuing microservices. With the right infra and culture, microservices will empower you and not get in your way, like this video suggests.
There are more problems with microsservices that are never addressed: As you divide the codebase into smaller modules and separate them into teams, you start moving away the focus from a techincal and programming based system into a more process and bureaucratic system. There's a lot of communication between teams in order to make any change at all and developers are alienated away from the entirety of the business logic. Changing code or understanding it now requires lots and lots of communication, and although that might sound good, it is the foundation for purely bureaucratic and slow work. Your system is now a bureaucratic. Isn't that the worst thing that could happen to it?
This is something that's invalid about microservices. The goal of microservices is that each individual team will be able to deploy each service, independent of each other. Each service doesn't need to know the existence of other services. Therefore, reduce inter team dependencies. If your microservices creates inter team dependencies (tight coupling), then what you build is distributed monolith.
me thinking it's a clickbate.. the guy with combophone : hold my beer jokes apart but it is true.. i personally feel its way easier to develop new features in a monolith.. atleast when you're in a PoC or an MVP stage... later on you can evaluate if you really want to move into microservices.. this is my experience.. would love to hear from other viewers what are their thoughts!
@@devagr Microservice is an Architectural choice based on context. You choose the tools to use and the implementation strategy. I find it strange to just advice against any pattern without context. You should do microservices if your business is very elastic, requires extreme scalability especially at peak workloads and your customers have the budget to support it. You need the right tools to support your decision. Serverless micro services is great if you have the skill set and budget. Whatever you do, make your decision based on the context. Don’t follow misleading advice based on bad practices.
Unless you have too... Start with them first so when you need to scale you dont need to create them and rearchitect your app. Whats your background? This is honestly not great advice and it seems like you dont have a lot of experience working with high scalability systems.
@@devagr hard to watch and not trying to waste my time. Not watching something clickbaity that says something opposite of popular opinion so people watch the video *lame tactic*. its super expensive for a company to build something a second time when they finally have traffic and need to scale. Thats actually why most businesses fail.. could you imagine hitting a million users unexepectedly and then going shit we have to scrap this it doesnt scale when you finally have users.. so now under a ton of pressure from the business we have to build something new quick that does scale so we dont lose users. So now instead of spending on just marketing the business has to spend double the amount on marketing and development. Its a nightmare for business and development. Ive been here too many times where i had to rebuild ruby on rails apps as microservices so the app didnt crash under load every few hours.
@@joshbedo8291 oh so your entire argument is based on "could you imagine hitting a million users unexepectedly". got it. Also microservices is not a scalability solution, it's a complexity solution. I can build a monolith app that can scale to a million users no problem. If you can't do that then you first have to learn how software architecture works. Also the opinion to always build microservices was popular like 4 years ago, not anymore. "Don't build microservices" is barely a hot take
Never thought I’d be learning software development from someone using a comb as a microphone holder… excellent innovation and excellent video!
It's a noise cancellation used 4000 years ago 🤣
lmfao, I love how your comment popped up at the top, made the video even better :D keep the white plastic comb for future videos, it's a trademark :D
A decoupled modular monolith sitting behind an API gateway makes it easier to migrate to microservices in the future if needed
Agreed
There is something in between, there can be parts of your product that make sense to put in a different service.
Grab the easy wins, you don’t need to call it micro services. And you definitely don’t have to put every package in its own micro service, like some people seem to think. A lot of the times micro services are just monolithic apps with added network latency 😅
Agreed, I didn't touch that in this video, because I wanted to keep it simple and short. I will talk about this more in upcoming videos
Here from Theo. Great vid! Love the humor, and the advice makes sense.
The lesson is don't over engineer your projects. My projects can benefit from microservices, but it is a PITA managing distributed transactions for sure. I would also agree that going from a monolith to a soa usually ends up in a complete overhaul so it isn't really migrating, it is more starting over with a more scalable design.
I'm a junior dev. I started really getting interested into Software architecture like two weeks ago and heard about micro services. After that, I told all my friends how "good" they were (based on what I've watched and read about it) and today I had to build an API so I said to myself "lemme try this". Idek if what I did could be called microservices, but I tried to follow the concepts and after two hours, I just created another repository and build my good old monolith :). Now after watching your video I feel like a litteral potato. Guess I will send this to everyone that I've preached to about microservices XD.
Thanks for the knowledge, looking for more in the future😁
I worked for a stupid company that want to use microservices with Laravel(PHP framework). They used this architecture: Laravel API Gateway -> Microservice 1 -> Microservice N. It was really SLOW in production also I don't see the point of microservices if A depends of B and always you call A you must call B. Also I think they NEVER consider the cost of that microservices, we have a Kubernetes, and about 10 diferent microservices, only for tests the company spend like 346.46 every month :/
Absolutely enjoyed this video!! Especially the makeshift mic 😄
Dude ! Thank you so much for this video.
Love your setup btw 😂❤
From my point of view microservices is not all about scaling, your can scale monolith easily just like microservices. Microservices help our team develop multiple features without worry about gitflow, conflicts, all component are easy to version up, refactor or replace. So its not based on how big your system, its about how many teams are working together.
Microservices is the perfect example of 'Monkey sees monkey does'.
“Hey junior developer. I know you don’t know much about software development, let alone architectures and infrastructure, but you should definitely be building micro-services” - there are people who think this is a good way to go
Imagine having to rollback a transaction across a dozen microservices 😅 btw totally diggin' the comb
I disagree about the monolithic codebase. The development experience depending on the project maybe great, but the deployment process can be really ugly depending on what tools you are using. I would rather build microservices and deal with their difficulty of maintaining them and etc then building a huge monolith and mainting its one big chunk.
I liked the finishing of the sentence from the thumbnail in the video.
haha, nice ending...agreed micro service strategies are more geared toward larger scale projects (we do this on my corporate side) for reusability, hot fixes, tech debt, maintenance strategies...
but I feel you can start taking a reusable approach if you use techniques like duck modular approach for directory structure or developing in a "mono" structure (root directory handles the system stuff, apps directory houses the projects, packages directory houses the "micro services" such as a design system or linting configurations)...
Lol this guy is hilarious and very knowledgeable. Thanks for posting!
2:50 - 2:60… Had to rewind to rewatch that, epic 10seconds😂
I read this argument before. But I needed someone to say this in video. Thank you for saying this publicly. I agree with you.
before watching the video, my (candid) opinion: serverless event driven architectures are pretty cool:), it's okay to introduce some kind of links between services
Building an app in django and have started worrying about scaling. Rethinking microservices Lamba, API Gateway, SQS, DDB, REACT and how about mobile apps.
You can literally just replicate the app across 2 containers and instantly achieve twice as much scalability
Great advice. And when when scaled, microservices seems like a waste. Why not think of services in general. If some of them end up being micro, that's fine.
Microservices is a paradigm to encourage narrowing scope for services, not an architectural plan.
I don't know if I agree that monoliths are flexible... But what you are describing is a distributed monolith and it's a design problem, nothing to do with micro services. Nowdays you can be more agile with microservices if you leverage cloud generic systems (serverless).
You build a well sized system in a week. Authentication, comunication and scalable processing. Even robust analytics and observability
thank you, monolith monk 🙏🏼
Spicy take ❤
Jeez, I was on a way to build a side project and I saw this video recommend by Theo.
I still wonder what would be the best architecture for small to mediums business.
3:05
YOU WILL BUILD A MONOLITH
REPEAT AFTER HIM:
I will build a monolith!
It really doesn't make sense to start a brand new project with microservices as an expectation, but if the codebase is designed well, pulling out a chunk of domain into one later shouldn't be too hard. Project I'm working on now was a mono for the first two years or so of it's life, but eventually the boundaries of certain functionality became clear that it could be segregated.
People using PHP may naturally build microservices without even thinking about these issues, specially if performance is not much of an issue. A microservice is just some file in some folder that does one thing. At a small or MVP scale, it doesn't even get called very frequently, so it's fine if it's stateless and the process always has to get everything it needs for each request.
If u can comfortable in your native(probably Indian) accent , please speak in your upcoming videos apart from them excellent explanation
This accent is quite natural to me now, I don't think I will be comfortable in an Indian accent.
I don't agree. It is not so difficult to build microservice for a new project.
But it is difficult to migrate a big monolithic (legacy) to microservice.
This video has me hooked. U made perfect sense.🤣🤣
thanks dev
Excellent talk! (I never bought into the hype, and no I'm not Netflix, lol)
here from Theo
this was hilarious haha. great video
It's probably worth mentioning that this applies to personal projects and small startups, not the majority of software out there. If you're part of a company (such as Netflix, Uber and thousands of others) that has a culture that promotes microservices, the path of least resistance to deliver features will be through microservices.
And what about other companies like Facebook. They have monoliths
@@jorgetirado2816 my point is for people not to get discouraged from pursuing microservices. With the right infra and culture, microservices will empower you and not get in your way, like this video suggests.
I think you are talking about distributed monoliths rather than microservices.
So good bro
Keep up the amazing content. You microservices videos are seriously the best breakdown I've ever seen.
I. will. build. a. monolith. 🙏
What about serverless and edge functions?
What does that have to do with microservice vs monolith?
There are more problems with microsservices that are never addressed:
As you divide the codebase into smaller modules and separate them into teams, you start moving away the focus from a techincal and programming based system into a more process and bureaucratic system. There's a lot of communication between teams in order to make any change at all and developers are alienated away from the entirety of the business logic. Changing code or understanding it now requires lots and lots of communication, and although that might sound good, it is the foundation for purely bureaucratic and slow work.
Your system is now a bureaucratic. Isn't that the worst thing that could happen to it?
This is something that's invalid about microservices.
The goal of microservices is that each individual team will be able to deploy each service, independent of each other. Each service doesn't need to know the existence of other services. Therefore, reduce inter team dependencies.
If your microservices creates inter team dependencies (tight coupling), then what you build is distributed monolith.
I will build a monolith!
me thinking it's a clickbate..
the guy with combophone : hold my beer
jokes apart but it is true.. i personally feel its way easier to develop new features in a monolith.. atleast when you're in a PoC or an MVP stage... later on you can evaluate if you really want to move into microservices.. this is my experience.. would love to hear from other viewers what are their thoughts!
I will build a monolith...
feedback: lighting is bad
thanks, I no longer record here and my new setup as better lighting
🤭
Lol
Hahaahhahahah
Nope
Another bad advice
How so
@@devagr Microservice is an Architectural choice based on context. You choose the tools to use and the implementation strategy. I find it strange to just advice against any pattern without context. You should do microservices if your business is very elastic, requires extreme scalability especially at peak workloads and your customers have the budget to support it. You need the right tools to support your decision. Serverless micro services is great if you have the skill set and budget. Whatever you do, make your decision based on the context. Don’t follow misleading advice based on bad practices.
Unless you have too... Start with them first so when you need to scale you dont need to create them and rearchitect your app. Whats your background? This is honestly not great advice and it seems like you dont have a lot of experience working with high scalability systems.
2:21 addresses this, and in the future I'd recommend watching the entire video before commenting
@@devagr omg you have your first hater!!!! They grow up so fast :')
do things that don't scale
@@devagr hard to watch and not trying to waste my time. Not watching something clickbaity that says something opposite of popular opinion so people watch the video *lame tactic*. its super expensive for a company to build something a second time when they finally have traffic and need to scale. Thats actually why most businesses fail.. could you imagine hitting a million users unexepectedly and then going shit we have to scrap this it doesnt scale when you finally have users.. so now under a ton of pressure from the business we have to build something new quick that does scale so we dont lose users. So now instead of spending on just marketing the business has to spend double the amount on marketing and development. Its a nightmare for business and development. Ive been here too many times where i had to rebuild ruby on rails apps as microservices so the app didnt crash under load every few hours.
@@joshbedo8291 oh so your entire argument is based on "could you imagine hitting a million users unexepectedly". got it.
Also microservices is not a scalability solution, it's a complexity solution. I can build a monolith app that can scale to a million users no problem. If you can't do that then you first have to learn how software architecture works.
Also the opinion to always build microservices was popular like 4 years ago, not anymore. "Don't build microservices" is barely a hot take