What Comes After Microservices? • Matt Ranney • YOW! 2016

Рет қаралды 18,206

GOTO Conferences

Күн бұрын

Пікірлер: 29

@willem18241 11 күн бұрын

Came here after your talk on NeetCodeIO. Love the talk

@vinay1744 2 ай бұрын

What comes after implementing Microservices: Pain!

@havokgames8297 20 күн бұрын

Puppies!

@GOTO- 2 ай бұрын

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.

@neilhatly 2 ай бұрын

Can you prepend the year, so we can see immediately it's almost 10 year old content.

@GOTO- 2 ай бұрын

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.

@joelbiffin Ай бұрын

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.

@NebraskaWriter 28 күн бұрын

This presentation is a tour de force. Bravo and well done, sir.

@Tango-tt6dx 2 ай бұрын

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.

@JavierBonnemaison 2 ай бұрын

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.

@joelbiffin Ай бұрын

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?

@bbrandttx Ай бұрын

This is a great update from Matt, now at DoorDash: kzbin.info/www/bejne/gpStfKuGjb6omqc

@JosifovGjorgi 2 ай бұрын

What Comes After Microservices? - Common sense

@mylesdear 8 күн бұрын

Composable event processors 41:54 sounds eeriely like chain of responsibility pattern that I've seen used in telephony call processing.

@MohamedSamyAlRabbani 2 ай бұрын

micro services are very slow, very expensive, resource intensive and take forever to add new features. Most developer's time is wasted doing nothing.

@nickngn Ай бұрын

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.

@visionmajor7300 Ай бұрын

Diddy was running microservices in his freak off mansion so my answer is jail. Jail comes after microservices.

@iliyan-kulishev Ай бұрын

LMAO

@RoamingAdhocrat Ай бұрын

was it nanoservices?

@KeeperKen30 17 күн бұрын

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.

@fennecbesixdouze1794 28 күн бұрын

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.