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.
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.
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.
Came here after your talk on NeetCodeIO. Love the talk
What comes after implementing Microservices:
Pain!
Puppies!
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.
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.
This presentation is a tour de force. Bravo and well done, sir.
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:
ruclips.net/video/LcJKxPXYudE/видео.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.
Diddy was running microservices in his freak off mansion so my answer is jail. Jail comes after microservices.
LMAO
was it nanoservices?
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.
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.
I'm a bit outdated developper, what's the current trendy architecture model please ? :)
@@vincentprince1833 monolithic microservices
Just monolith brother
Rest well
How does a async message queue lead to more decoupling? Doesn't it make it easier to couple services?
layoffs
Microtransactions.
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!