Another double edged sword of microservices: Teams own services. So, changing your own service is pretty easy, but changing other people's service's can be very hard (if there isn't an explicit push for a collaborative culture). In a monolith, everyone feels like they softly own parts of the code, but you can change anyplace (say, during a refactoring). Try refactoring some global stuff in a business using microservices... There are two ways: sending MR for every repo yourself (which is not trivial, because you don't even have access to them), and people can and will ignore you. Beg people to do it, which is such a failing strategy because they don't have any incentives to do it. So you probably need some strong company process / culture that enables global changes (I've never seen it in real life).
@Pharoah2
14 сағат бұрын
Yearly roadmap/architecture reviews are exactly what this is for. What level are you at where you’ve never even heard of these discussions?
@georgehelyar
14 сағат бұрын
The way we do it at my work is that anyone can make a change to any service but it has to have tests and it has to be reviewed by the owning team. If e.g. someone creates a pull request without tests, you just reject it until there are tests. If they don't understand the consequences of their change you talk to them and discuss a better solution. Most of the time changes are simple enough to be accepted though. Consumer driven contract testing is also useful. If you have to submit a PR/MR for every repo then you probably need to rethink why there are things repeated in every repo e.g. could they be packages or yaml templates etc.
@bjornarnols5905
14 сағат бұрын
I work in a monolith and I don't feel like I own any part of it. even the parts of it I built from scratch have to play ball with the (in this case extremely stupid) architecture someone else made up years ago since a total rewrite isn't in the cards rn.
@nathanhughes8354
14 сағат бұрын
yeah making MRs for other people's stuff isn't going to happen. The only way for a global change to happen is serious carrot/stick stuff. either there is some shared facility people want to use where they have to upgrade in order to make use of it (like if you want your logs to show up in splunk they're going to have to adapt to the prescribed format), or like with vulnerabilities or cloud migration or whatever, there is a big dashboard that shows who is out of compliance and the management is ready to mete out punishment.
@awb19892
14 сағат бұрын
if your team owns the monolith, and it grows and you now grow to 3 teams to own it all, how do you transfer ownership of various parts in a clean way? if you need to make changes with microservices and other teams own that stuff, these are external dependencies you should get buy-in (and coding partnership, if needed) for upfront, not at the last minute. I have seen situations where monoliths are owned jointly by a bunch of different teams... and all MRs get blocked until some integration tests get fixed. Most people sit around waiting, and the second it's finally fixed (which can take weeks), everyone jams their MRs through (after resolving merge conflicts) and the tests break again, and MRs get blocked for another couple weeks. We even set some things up where one specific dev had to approve every single PR (100+ total devs) for a while to try to stabilize things. It was a huge mess. That said, the places I've worked at that used microservices had much better devs and much better design/code/testing quality than places I've worked at that used monoliths, so it's not a perfect comparison.
@enerjiCS
17 сағат бұрын
the fit goes hard bro
@adnan7698
16 сағат бұрын
Black hoodie?
@ismbks
16 сағат бұрын
@@adnan7698 stop baiting bro
@MichaelZijlstra
15 сағат бұрын
This made me think of Conway's law - the structure of a system reflects the structure of the organization that makes it. They had to split into micro-services because their organization became too large.
@smanqele
15 сағат бұрын
We don't even do Microservices the way they are supposed to be done, just like OO programming got out of hand with wanting trivial classes that just serve one call over their entire existence
@xkjjx
13 сағат бұрын
say a group of functions in total processes >5 inputs and outputs >5 outputs - creating a class to manage that, and then getting the outputs by calling getOutput1(), getOutput2() is a cleaner way to do that in my opinion
@andrewmarek
16 сағат бұрын
This is a cool video! I feel like everyone has read that blog (independent of your channel) or a blog similar to it, and having someone come back and reflect on it is really valuable.
@matowang
15 сағат бұрын
Love this talk by someone who actually works in the trenches Too much theory talks about microservices out there
@nicholastanzillo4229
15 сағат бұрын
I don’t comment often… but this is an incredible video! If you can, I hope you’re able to get more people like this on the channel!
@NeetCodeIO
13 сағат бұрын
I would love to, glad people enjoy deep technical talks as much as i do
@naninano8813
15 сағат бұрын
Wow what a breath of fresh air! agree with most points. def shows what a seasoned architect can be
@sumitkumarmahto5081
16 сағат бұрын
A really nice point mentioned : there has to something in between, you can’t only have two options : monolith or a microservice. This is probably done by a lot of teams where they carefully break their overall app. They just don’t go say each module needs to be a separate service, rather how close are these two modules to each other and can they perform better together. If there would be tool for this, that would be great.
@spartanghost_17
15 сағат бұрын
There are inbetween steps dude
@arturfil
14 сағат бұрын
That would be the same as having a service separate to each other but shares the same db. Like there’s a separation of logic but not of data retrieval. Otherwise you have a monolith if you share functions writhing the same project or services if they have to do a rpc’s for function communication.
@codefast93
16 сағат бұрын
Idk if microservices are “better” overall but they are painful to develop: Setting up all the individual repos as submodules in one parent repo, dealing with all the messaging, individual deployment etc
@yassinesafraoui
16 сағат бұрын
Yeah, they're not meant for a team of a few devs, they're meant for very large teams as discussed in the video, and it makes sense for those large teams because the overhead you're talking about is affordable for them. But it does make it hard to learn them on your own without being in a company using them as you have to deal with that overhead 😅
@jorshaw86
16 сағат бұрын
I'm actually a proponent of the monorepo with many services. The trade off is you need something like bazel for build and unit testing which has to be maintained but if you have a lot of services could be a net benefit
@yassinesafraoui
16 сағат бұрын
@@jorshaw86so you mean that building and testing micro services is easier than monoliths. That's also a valid take I think
@jorshaw86
15 сағат бұрын
@@yassinesafraoui no I think building and testing can be harder on microservices because if you have a large dependent graph getting all those spun up for integration testing is harder than a single binary or coping all your interpreted files to a docker container or server and running a single interpreter over them. The monorepo is just a comment on how you organize your microservices. E.g. separate services doesn't have to mean separate repos. Assuming your company has the people or expertise to maintain a build tool like bazel you can have your services in a single repo and run build and test together. This saves some overhead of having to maintain N repos where N is the number of microservices. I've only had bad experiences with submodules and subtrees so I stay away from those like the plague.
@ButaNgamuk
16 сағат бұрын
They need to define what microservice is first before discussing it. Microservice is not just replacing function calls with GRPC.
@Fran-kc2gu
16 сағат бұрын
That's obvious
@lucasteo5015
16 сағат бұрын
Simplicity is always the best, stick with monolith until you actually face performance issues. Complicate things up only when it is absolutely necessary. In terms of OOP only create hierarchy when you absolutely need that inheritance otherwise keep everything as dumb as possible.
@jorshaw86
16 сағат бұрын
I agree with almost everything being said here. I think there needs to be a reaction to the mid 2010s of microservice everything which caused this distributed monolith problem which is net worse than a regular monolith. Ultimately you have to be critical about the workflow and if you always need service B for service A and service B isnt being used by something else then they should definately be the same service. I think rather than counting total microservices i think people should count dependent microservice graph. If you need to call 100 services todo a single workflow that should be a big red flag. I dont agree with what he is saying about testing but get the sentiment but i think it comes down to internal engineering culture. IMO assertion quality check is called peer review. If people are writing or approving code that is blatantly not asserted on correctly that is a problem. What allows microservices to scale is contracts what helps ensure your contracts are you tests. So that can contribute to the distributed monolith if you dont have strong contracts because you dont have strong tests things can degrade fast. Also contract testing for every team i have been on has been a game changer in terms of being able to effectively "integration" tests on a service gives the developer or development team a higher degree of confidence in their change before it goes into a pre prod env for full integration testing. I think the TLDR of this is in SW engineering theres no free lunch. With microservices you gain deployment velocity and workflow isolation but that opens up a bunch of other considerations around how you think about persistence, curcuit breaking and tooling.
@dream_emulator
13 сағат бұрын
Great interview! Have lived this struggle.
@rotteneggconcept
15 сағат бұрын
Microservices should be Edgecase, but this somehow becomes a pissing contest, adding Complexity for the Sake of proving Intelligence. Im guessing thats why Shipping Products has become almost impossible
@jasonwoods2292
16 сағат бұрын
The comment towards the beginning, about "no one" taking down a system to deploy anymore, shows how insulated folks like this are to how many enterprises run even today. One moral to this story is, understand who's telling you how you should architect a system, and what your constraints actually are, before following their advice.
@mjrmjr4
14 сағат бұрын
That is a fair callout. All of the systems that I’ve worked on in my career have been internet connected and expected to be online always. But there are plenty of systems that are not like this, and for those you can make different tradeoffs.
@sbergen
13 сағат бұрын
Mutation testing can measure assertion quality! It has its limitations, and can be slow (especially if your tests are slow), but it's really powerful in certain contexts! See e.g. Stryker Mutator (supports JS, C#, Scala).
@javedshaik8105
14 сағат бұрын
Apart from the techincal knowledge, we really see how to communicate well with respect when talking to a senior. Which can be applied in an interview as well. Thanks a lot!
@dataai514
14 сағат бұрын
This was a really good talk. It's especially useful for beginners who might get sucked into the microservices dogmatic ideal. Thank you!
@Nellak2011
13 сағат бұрын
Correct me if I am wrong, but basically: - Normal Monolith = Drinking Coffee in the morning and eating mostly healthy - Microservices = Taking Meth and eating somewhat healthy - Distributed Monolith = Taking Meth and being very unhealthy - Modular Monolith = Eating Healthy and staying fit through discipline for natural energy
@princeani3929
14 сағат бұрын
Absolutely love this kind of content. More of this pls. I would pay for these kind of interviews with actual battle tested devs vs LinkedIn cringe.
@chralexNET
13 сағат бұрын
Interesting talk. It is always important to keep in mind that principles and what is taught is always going to be ideals, and often always have idealized solutions and issues as examples. So, in the end it is always just guidelies that can help you think about how to design/architect or develop, and if there are good reasons not to follow those ideals then absolutely you are justified in doing something else, which is what happens as soon as any ideal meets the real world, at least to some extent, depending on the resources you have.
@Etcher
13 сағат бұрын
Awesome video, amazing to get a follow up to your video with the guy who left a comment noting he was a lead engineer at Door Dash. Really interesting hearing his take on things.
@milanpanic3755
13 сағат бұрын
Majority of the “microservice” architecutres I’ve worked on were SOAs with small services 😂😂
@gaulcore
13 сағат бұрын
great video, thank you matt for coming on
@LukaszKubica
16 сағат бұрын
We are an isv for telco industry and our customers explicitly require us to have microservice architecture in their rfps... So it got to a point where their enterprise architects who probably has not developed anything for decades are trying to architect our products. This is a totally crazy situation. It got to the point that microservice is a synonym of a best of breed architecture even though it does not work for some problems at all.
@Endorsememe
15 сағат бұрын
On java side, Spring Modulith is kinda something that tries to fix this issue.
@siddarthsaha5364
15 сағат бұрын
neetcode is becoming one of my favourite hardcore programming channels
@133839297
14 сағат бұрын
Such a great conversation. Thanks. Bring the neetcast on. 😂
@salookie8000
13 сағат бұрын
I’m having a problem where some microservice owners take too long to finish work. Not every programmer develops at the same speed. I provided that person help and he still remains quietly working slowly.
@maduk22
14 сағат бұрын
Please continue this type of videos !!!! I hope you turn it into aserie where you bring distinguished engineers and talk all things engineering and management, for example one interesting topic is did they integrate ai in development workflows ? How ? What impact it did ?
@fortrolol
16 сағат бұрын
Very interesting perspective, thanks!
@mofekayode8944
14 сағат бұрын
This is amazing! Please do more of this
@yaashbruh
16 сағат бұрын
I think it's missing some points: * Compartmentalization - one feature could fail, don't take down everything * Error handling - sure, everyone in the call chain is getting paged, but that call chain is normally for a subset of functions, vs everyone who works on the monolith It's also possible to create microservices without network calls. There are frameworks like vert.x which basically build a monolith up from individual smaller components (best of both world).
@trailerhaul8200
15 сағат бұрын
Without network call, your component can only be on one host. And a host hardware and software failure, it will bring everything down?
@richie.edwards
14 сағат бұрын
Thanks for sharing this wonderful conversation.
@boot-strapper
15 сағат бұрын
Matt is 100% right, microservices are mostly a social solve.
@Kaviarasu_NS
16 сағат бұрын
Been binge watching NeetCode for past 6 months, finally have said Hi to you in my dreams yesterday.
@TwoLeggedTriceratops
13 сағат бұрын
hmmmmm
@NeetCodeIO
13 сағат бұрын
hihi :)
@logman3455
13 сағат бұрын
It seems that a lot of the issues caused in the software industry are by companies that needs to grow as big as possible as fast as possible and honestly warning signs are popping up all over the place that this is probably not the best way to do things if you want them to last.
@nikilk
14 сағат бұрын
What about being able to code up a service in say C#, another in Node, another in C, or Java.. That ability to switch is a freedom to fast but sure that also means change is owned by those teams that built it. It's similar to how our body's are built in a microscopic level. Each cell has it's area of responsibilities and that expands to organs to the collective organism to a society of collaborating organisms. To Countries and world politics. We are a real life implementation of Micro Services ;). Imagine if everyone spoke the same language, the same culture. The Diversity is what makes things work. Aka Micro-services :)
@Milaneuh
14 сағат бұрын
Checkout Modulith from Spring
@syphondu
16 сағат бұрын
Reasonable but missing some considerations: Is functionality written in the same language? Are performance and security postures skewed heavily between parts of the monolith?
@catjamcoin
13 сағат бұрын
Microservice connectivity is another challenge.
@salookie8000
13 сағат бұрын
There are Docker tools to ensure microservices are always online.
@ChethanV-gi8io
16 сағат бұрын
Great video!
@hanuman9
13 сағат бұрын
If you create micro-services to make teams more independent, why do you need 500 services? If you have 12 teams of 20 people each, can't you just create 12 services, each containing their own sets of modules?
@oggatog3698
14 сағат бұрын
release train + feature flags + feature flag removal nag bot = happy monolith
@sudo_garrett
17 сағат бұрын
great video!!!
@awb19892
14 сағат бұрын
On unit tests, I don't care about the number at all really. Of course bad coverage implies something is missing. But we have staff devs in my org just mocking and patching the hell out of everything, and doing "assert is not null" or "verify did call X function." Straight up heard these devs in meetings saying they do not care about software engineering principles. They have "99% coverage" but it's all fake nonsense.
@geetpatel5071
16 сағат бұрын
Neetcode got that blanket drip
@RoflcopterWosh
13 сағат бұрын
can you put the links he shared in the google meet chat? Like put it in the video description
@igboman2860
14 сағат бұрын
Also lets be real i dont know the size of doordash. Some codebases are over 15 millions lines. Try building that and releasing it everyday without more insane tooling such as complex build systems like bazel
@FranzAllanSee
15 сағат бұрын
Do this one feature and you need to modify in 3 different services. you need to sequence the deployment of the different services. sharing databases. I dont want to be that guy, but this just seems like distributed monolith right?
@igboman2860
14 сағат бұрын
Everything is technical debt. Menh
@ilovecatsandgyat
15 сағат бұрын
Interviewed with Doordash recently. They were asking questions like "how did you help minority people at your workplace?". The systems design rout was really unpleasant as I was constantly interrupted lol
@dawidjanik937
16 сағат бұрын
@NeetCodeIO, can you include those 2 links shared during the call in the video description?
@yuri.caetano
17 сағат бұрын
First 🎉
@patricknsukami1587
17 сағат бұрын
Second 🎉
@saimanoj8171
17 сағат бұрын
Third @@patricknsukami1587
@sumantakollya8573
17 сағат бұрын
Third🎉😂
@sarkar_957
17 сағат бұрын
@@sumantakollya8573 Fourth 🎉
@daa5249
13 сағат бұрын
@@sarkar_957 You weren't the fourth, scroll down and relinquish all your fourth prizes!
@xes.software
15 сағат бұрын
So many theories on how to scale software, OOP, microservices, etc... Literally all of them suck at scale. I don't think these theories are objectively terrible, I just think software sucks at scale.
@debapratimshyam149
15 сағат бұрын
Great talk can you post the links in the video description ?
@11folders
15 сағат бұрын
Thanks for the interview! Can you share the links/articles he mentioned?
@bangbang86
16 сағат бұрын
Navi’s body looks like Hulks in the intro section 😅
@stephenmcguckin7120
13 сағат бұрын
Sound like too many microservices. You should avoid calls between microservices. Architect around that. Instead of making calls between services in some situations it’s better to replicate data as long as your fine with eventual consistency.
@jonathan-._.-
15 сағат бұрын
micro = 1/1000000 so theoretically it would be u need million microservices to make up one service i'm more of a fan of approximately deca services (patent pending :3) like 1/10 of a service seems like a good size 🤔
@naughtiousmaximus7853
16 сағат бұрын
So I am solo dev building a system that is akin to ERP with bunch of features but on the small scale (car audio equipment for my uncles business). What benefit could I possibly get from microservices if I for example use a vertical slice architecture, properly separate concerns between features and then extract common reused code into generic interfaces/classes/methods that can later be turned into a NuGet package? Its much easier to deal with monolithic codebase on this scale, where at most, EVER, we might get like 200k requests PER DAY.
@yassinesafraoui
16 сағат бұрын
If you don't have a large team, I don't think micro services are for you, that's what I understood from the video. But still you need some structure in your codebase since it's a large project
@naughtiousmaximus7853
15 сағат бұрын
@@yassinesafraoui yes, thats why VSA rocks
@ohdude6643
13 сағат бұрын
This is Linux Kernel vs GNU Hurd all over again.
@Maxშემიწყალე
16 сағат бұрын
Him polarizing his AP in the incorrect direction triggers me so hard.
@mjrmjr4
14 сағат бұрын
You are welcome to come do the drywall work in my office to mount it from the ceiling.
@kevinhe7
15 сағат бұрын
I disagree. He doesn’t know what he is talking about.
@stephenmcguckin7120
13 сағат бұрын
Sound like too many micro-services. Instead of making calls between services in some situations it’s better to replicate data as long as your fine with eventual consistency.
@justinjustin4605
16 сағат бұрын
1000 calls to place and order??
@TheAfterbreak
13 сағат бұрын
Good vid
@ErnestoConfused
16 сағат бұрын
such a cool shirt. This video gets a comment and a like, just because of the shirt.
@mostlygibberish
15 сағат бұрын
From where I came from, microservices and serverless are the two most frequently quoted thing by fake paper architects to impress clueless bosses armed with gartner quadrants
@ShailPM
13 сағат бұрын
nice
@SanjayB-vy4gx
14 сағат бұрын
Share those links bro
@yoashbentulila8638
13 сағат бұрын
who's the guy from Doordash?
@wikixen
15 сағат бұрын
Can you include the links that Matt sent you at 16:47 in the description
google meet link is visible. Is it possible to get some info from just meeting link
@ausika
15 сағат бұрын
microservices should never share databases
@salookie8000
13 сағат бұрын
I do. I use .env to point to database name and FQDN. Don’t replicate DB tables to different databases. Keep it simple. Microservice SQL should specific to a domain. Copying domain data to another domain doesn’t make sense to me.
@ArunNegi-fi8di
14 сағат бұрын
let me tell you , you will eventually end up using your services API key as 3rd party and there will be multiple monolith summing up microservices .
Пікірлер: 137