We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
Thanks for your input. We used to do it that way, but noticed that the talk title and especially the speaker name gets pushed out of sight, which is just as important to many viewers.
This was a great talk, especially given that we are now 8 years post and these topics are very much up for a successful company to figure out for themselves still. It seems that in the RPC world, engineers are still thinking in an "in-process" style. That doesn't mean it's bad at all, but it just means that a function to retrieve "some thing" just returns the object they need. This mindset though, is the mindset of most web programmers (me included). For scaling up, it makes sense for engineers to continue thinking that an HTTP call to a service is just like calling a function. But I guess the point of this talk is that, in those scale up times, RPC continues to make the customers and engineers happy, but it's technical debt which will make the next change much more difficult.
Sounds like as of 2016, when this video came out, Uber had built themselves a distributed monolith to run its core functions. I would be really curious to see how things evolved and ended up in 2024.
I agree, but is that actually bad? I mean they continued to grow and scale whilst doing so. It seems like Netflix had a similar story. Despite the purity of Event Driven Architecture, is it so costly in the early stage of development that it stifles innovation?
watched it at 1.5x - aged very well, unfortunately. most of the talk is about problems with Microservices Uber encountered while change coupling is highlighted. Most of it should be familiar for interested devs of 2024. The other part of the talk is about composabbility as a desired solution to takkle change coupling in my understanding. Good takes on composabbility in synchronous Architecture. In my words, with the increase number of services cross cutting changes are a problem because most services may need to adapt to the new requirement. And cross cutting changes are quite common. Hence, some kind of solution is desirable where composabbility is facilitated like by intercepting flows without changing collaborating services. I did not really get the desired direction - Based on the other topics he talked about I assume some kind of messaging based workflow coordination coupled with synchronous communication, I guess outgoing from the coordinator. Yet, the last slide suggested some kind of interception / interruption of a flow, I can't get my head around when the goal is not to change other services. So, what comes next? There was no direct answer for architectures imho. And in 2024 I think my answer would be, whatever architecture works for the business requirements. I think the industry moved away from fully distributed or total monolithic architectures - so something in between.
Actually the video doesn't answer the question in the title. But I think it may be new modular monolith, which modules communicate to each others by events, APIs, etc like Spring Modulith is doing. This leverage the power of monolith but also ensure decoupling modules.
What we're talking about here is system architecture, which is goals-driven: you identify certain properties you want, and then you devise an architecture to achieve those properties. This talk seems to take the complete opposite vision: you find an architecture you want based on buzzwords and influencer hype, have no goal in mind as to what you want to accomplish, and then follow blindly whatever "best practice" you hear repeated often as "the right way" to do that architecture. The only two specific things mentioned in this talk: - goal: teams can work independently - best practice: don't share storage Obviously whatever they devised doesn't allow teams to work independently, so they weren't working toward that. And "don't share storage" is definitely NOT actually a "best practice", it's some junior-talk you hear parroted by people with zero experience. What's obvious is Uber doesn't have an architecture, it has a big distributed ball of mud that was set up as hastily as possible because Uber was in hyper-growth mode. No good ideas or good architecture at all were enforced, and buzzwords like "microservices" and non-principles like "don't share storage" were parroted as gospel to give a veneer of "doing things right". Let's take Ranney's example of Uber Puppies, and specifically his mention that the team will "have to coordinate with Populace (their user service) to build their feature". Why? He mentions that users will have preferences related to whether they like puppies or not. These preferences could be persisted in a separate Uber Puppies preferences service, keyed by userId. Or the user service could be like Amazon Cognito, which allows any service with permissions to dynamically add additional attributes to the user. Clearly if Populace's design requires the Populace team to crack open the code for the User service, just to build out a simple preferences object with a 1-1 relation to users, it hasn't been appropriately designed to allow teams to work independently on new services.
Microservices are not a problem, not one bit. Calling monolithic services Microservices when they are not is a major problem. Using unorganized Service Oriented Architecture and calling it Microservices is a major issue. Use Microservices correctly, they are outstanding. However, they are not a silver bullet (nothing is). Use the correct solution for each problem. You cannot simply lable any solution "Microservices", then complain when it doesn't deliver what you wanted. That is what Agile is for.
"Microservices are not a problem, not one bit." I beg to differ for the following reasons off the top of my head: -They provide Security issues with a higher attack service. -Add unnecessary complexity and necissitate the need for complex services like Kubernetes. -Network overhead as Grpc calls are costly etc... -Debugging is a challenge with distributed systems -Monitoring complexity -Data management issues etc...
@@Steve-cn5up Half your 'points' are true for any remote service implementation. I disagree with everything you've listed. Microservices, again, when done properly and not just labeled "Microservices" solve the problems you've listed. Like everything else, Microservices are NOT a solution to every problem. If you need tightly coupled services, then Microservices are not the solution. Stop calling everything (REST, gRPC) Microservices. Very few things are in fact Microservices. Service Oriented, but not Microservices.
@@KeeperKen30 Ok. Let's make sure we're on the same page with our understanding of microservices. Martin Fowler, one of the pioneers of microservice architecture, basically defines them as being a software architecture that breaks down large applications into smaller, independent services that communicate with each other through APIs. Do you agree with that? If so, please tell me how microservices don't add: -network overhead? -complexity with its distributed architecture? -increase the surface area for attacks? -Debugging challenges? -Monitoring complexity -Data management issues? -Technical challenges? -Organizational and Design challenges? -Vendor lock-in risks?
@@Steve-cn5up No, I do not agree. Microservices should be Small, Focussed on One Task, Aligned with a Bounded Context, Autonomous, Indpendently Deployable, and Loosely-Coupled (Taken from the outstanding Continuous Development channel). I define a Microservice as something that is not going to call other Microservices (that is okay for a Service). In short, the Microservice should be 100% independent. I can change it as needed without worrying about other services breaking. If a Microservice needs data from other services, there are ways to injest that independently of the Microservice (event driven/kafka, batch data loads into the DB). This is really nothing more than agreeing on the terminology. In my (and others) opinions, EVERYONE just ran with calling everything a Microservice because it was 'the thing' (like they did with Agile and so many other methodologies). Again, there is nothing wrong with coupling if you need to do it, just don't call that a Microservice (that is Service Oriented Architecture). A great overview that I agree with. ua-cam.com/video/zzMLg3Ys5vI/v-deo.html
Came here after your talk on NeetCodeIO. Love the talk
We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
Can you prepend the year, so we can see immediately it's almost 10 year old content.
Thanks for your input. We used to do it that way, but noticed that the talk title and especially the speaker name gets pushed out of sight, which is just as important to many viewers.
What comes after implementing Microservices:
Pain!
Puppies!
This presentation is a tour de force. Bravo and well done, sir.
This was a great talk, especially given that we are now 8 years post and these topics are very much up for a successful company to figure out for themselves still.
It seems that in the RPC world, engineers are still thinking in an "in-process" style. That doesn't mean it's bad at all, but it just means that a function to retrieve "some thing" just returns the object they need. This mindset though, is the mindset of most web programmers (me included). For scaling up, it makes sense for engineers to continue thinking that an HTTP call to a service is just like calling a function. But I guess the point of this talk is that, in those scale up times, RPC continues to make the customers and engineers happy, but it's technical debt which will make the next change much more difficult.
Sounds like as of 2016, when this video came out, Uber had built themselves a distributed monolith to run its core functions. I would be really curious to see how things evolved and ended up in 2024.
I agree, but is that actually bad? I mean they continued to grow and scale whilst doing so. It seems like Netflix had a similar story.
Despite the purity of Event Driven Architecture, is it so costly in the early stage of development that it stifles innovation?
This is a great update from Matt, now at DoorDash:
ua-cam.com/video/LcJKxPXYudE/v-deo.html
watched it at 1.5x - aged very well, unfortunately.
most of the talk is about problems with Microservices Uber encountered while change coupling is highlighted. Most of it should be familiar for interested devs of 2024.
The other part of the talk is about composabbility as a desired solution to takkle change coupling in my understanding.
Good takes on composabbility in synchronous Architecture. In my words, with the increase number of services cross cutting changes are a problem because most services may need to adapt to the new requirement. And cross cutting changes are quite common. Hence, some kind of solution is desirable where composabbility is facilitated like by intercepting flows without changing collaborating services.
I did not really get the desired direction - Based on the other topics he talked about I assume some kind of messaging based workflow coordination coupled with synchronous communication, I guess outgoing from the coordinator. Yet, the last slide suggested some kind of interception / interruption of a flow, I can't get my head around when the goal is not to change other services.
So, what comes next? There was no direct answer for architectures imho. And in 2024 I think my answer would be, whatever architecture works for the business requirements. I think the industry moved away from fully distributed or total monolithic architectures - so something in between.
What Comes After Microservices? - Common sense
Composable event processors 41:54 sounds eeriely like chain of responsibility pattern that I've seen used in telephony call processing.
Actually the video doesn't answer the question in the title.
But I think it may be new modular monolith, which modules communicate to each others by events, APIs, etc like Spring Modulith is doing. This leverage the power of monolith but also ensure decoupling modules.
micro services are very slow, very expensive, resource intensive and take forever to add new features. Most developer's time is wasted doing nothing.
What we're talking about here is system architecture, which is goals-driven: you identify certain properties you want, and then you devise an architecture to achieve those properties. This talk seems to take the complete opposite vision: you find an architecture you want based on buzzwords and influencer hype, have no goal in mind as to what you want to accomplish, and then follow blindly whatever "best practice" you hear repeated often as "the right way" to do that architecture.
The only two specific things mentioned in this talk:
- goal: teams can work independently
- best practice: don't share storage
Obviously whatever they devised doesn't allow teams to work independently, so they weren't working toward that. And "don't share storage" is definitely NOT actually a "best practice", it's some junior-talk you hear parroted by people with zero experience.
What's obvious is Uber doesn't have an architecture, it has a big distributed ball of mud that was set up as hastily as possible because Uber was in hyper-growth mode. No good ideas or good architecture at all were enforced, and buzzwords like "microservices" and non-principles like "don't share storage" were parroted as gospel to give a veneer of "doing things right".
Let's take Ranney's example of Uber Puppies, and specifically his mention that the team will "have to coordinate with Populace (their user service) to build their feature". Why? He mentions that users will have preferences related to whether they like puppies or not. These preferences could be persisted in a separate Uber Puppies preferences service, keyed by userId. Or the user service could be like Amazon Cognito, which allows any service with permissions to dynamically add additional attributes to the user. Clearly if Populace's design requires the Populace team to crack open the code for the User service, just to build out a simple preferences object with a 1-1 relation to users, it hasn't been appropriately designed to allow teams to work independently on new services.
Diddy was running microservices in his freak off mansion so my answer is jail. Jail comes after microservices.
LMAO
I'm a bit outdated developper, what's the current trendy architecture model please ? :)
@@vincentprince1833 monolithic microservices
Just monolith brother
Rest well
was it nanoservices?
How does a async message queue lead to more decoupling? Doesn't it make it easier to couple services?
layoffs
Microtransactions.
Microservices are not a problem, not one bit.
Calling monolithic services Microservices when they are not is a major problem. Using unorganized Service Oriented Architecture and calling it Microservices is a major issue.
Use Microservices correctly, they are outstanding. However, they are not a silver bullet (nothing is).
Use the correct solution for each problem. You cannot simply lable any solution "Microservices", then complain when it doesn't deliver what you wanted. That is what Agile is for.
"Microservices are not a problem, not one bit." I beg to differ for the following reasons off the top of my head:
-They provide Security issues with a higher attack service.
-Add unnecessary complexity and necissitate the need for complex services like Kubernetes.
-Network overhead as Grpc calls are costly etc...
-Debugging is a challenge with distributed systems
-Monitoring complexity
-Data management issues etc...
@@Steve-cn5up Half your 'points' are true for any remote service implementation. I disagree with everything you've listed.
Microservices, again, when done properly and not just labeled "Microservices" solve the problems you've listed.
Like everything else, Microservices are NOT a solution to every problem. If you need tightly coupled services, then Microservices are not the solution.
Stop calling everything (REST, gRPC) Microservices. Very few things are in fact Microservices. Service Oriented, but not Microservices.
@@KeeperKen30 Ok. Let's make sure we're on the same page with our understanding of microservices. Martin Fowler, one of the pioneers of microservice architecture, basically defines them as being a software architecture that breaks down large applications into smaller, independent services that communicate with each other through APIs. Do you agree with that? If so, please tell me how microservices don't add:
-network overhead?
-complexity with its distributed architecture?
-increase the surface area for attacks?
-Debugging challenges?
-Monitoring complexity
-Data management issues?
-Technical challenges?
-Organizational and Design challenges?
-Vendor lock-in risks?
@@Steve-cn5up No, I do not agree. Microservices should be Small, Focussed on One Task, Aligned with a Bounded Context, Autonomous, Indpendently Deployable, and Loosely-Coupled (Taken from the outstanding Continuous Development channel). I define a Microservice as something that is not going to call other Microservices (that is okay for a Service). In short, the Microservice should be 100% independent. I can change it as needed without worrying about other services breaking. If a Microservice needs data from other services, there are ways to injest that independently of the Microservice (event driven/kafka, batch data loads into the DB).
This is really nothing more than agreeing on the terminology. In my (and others) opinions, EVERYONE just ran with calling everything a Microservice because it was 'the thing' (like they did with Agile and so many other methodologies). Again, there is nothing wrong with coupling if you need to do it, just don't call that a Microservice (that is Service Oriented Architecture).
A great overview that I agree with. ua-cam.com/video/zzMLg3Ys5vI/v-deo.html
What comes after? Seems like something that should be in the title of this video. Not going to watch it.
> What Comes After Microservices?
The fashion for monolith will return under another name!