I would really enjoy a discussion with guys from Netflix and Uber. For me it sounds like both have completely different approaches to microservices. For me Uber sounds like the "common library" approach while Netflix is the "complete isolation" company. Uber considers it's code base as a whole, Netflix considers each service individually.
I'm sure Netflix has some common libraries for something as global as logging. I can't imagine each service re-implements every logging detail. I think it's most important to avoid common libraries for your actual business logic.
Yeah we can abstract everything. But not everybody is Uber. Ask yourself if you really need to. Indirection brings complexity, too. Also, monorepo is a funny come back of the modular monolithic. In more complicated.
does the tracing example really work like that in practice? How can all services depend on the same configuration and same server? same base server maybe but you’d want to set up your own endpoints in a constructor. And in that case you can just have every service use the same base server implementation and add a tracer for that. No need for dependency injection. Another point, does this really make devs more productive when coding global features? its usually much harder to follow the flow of code with a dependency injection framework as you don’t really know how your object was constructed, and that tends to be important..
It just have many best practices and concepts explained before by people like Uncle Bob and Martin Fowler. I like the way Uber's putting those ideas because they structures it simple . But it's very superficial. They could put more details about their code structure and best practices with monorepo to the community.
DI was an idea that went horribly wrong. Spring is a pain to troubleshoot. I consider DI to be anti-Go. I sincerely hope Go community does not bring in the mistakes of Java to Go.
@@JohnDoe-ji1zv DI is useful when you actually have multiple implementations of an interface and don’t know which one it will be until runtime. Sadly, DI is often abused and used when there aren’t actually multiple implementations. Seen many cases in my career where developers will use DI for everything regardless of if it really brings a benefit or not.
I thought go development was all about no magic very verbose coding so every thing is clear and no hidden stuff. But this doesn't look like the that. And all this concept looks awfully close to spring framework
interesting ..that’s not what go development is ‘all about’ ..not at all. perhaps it’s my experience alone but i’ve not ever heard it described that way before. never. to me golang is ‘all about’: performance, simplicity and expressiveness ..that’s just me though.
Is it me or do only the people with experience exclusively in Spring framework tend to equate everything else to it? - What's this "kuber--shmoober" thing they keep talking about? - Oh, Kubernetes? It's a container cloud that - Containers? So, another reimplementation of Spring, I see.
Такое ощущение, что по мотивам художественного рассказа написали уголовное дело. Да, мы работали с DI - конференция-то профессиональная. Монорепа на го - тоже мне новости. Вот эту всю шелуху надо было сжать до пары минут, а вот про мелочи реализации всё выступление и пиздеть - прям вот объявления типов из app.go показываешь и детально обосновываешь, почему они такие (со спецификой го, если она есть вообще).
well, one acronym: OSI; one word: layers; ... very basics of any swdev, imho; so I thought that slavery was prohibited in past centuries; nice that you now treat ppl as developers, instead ))
I would really enjoy a discussion with guys from Netflix and Uber. For me it sounds like both have completely different approaches to microservices. For me Uber sounds like the "common library" approach while Netflix is the "complete isolation" company. Uber considers it's code base as a whole, Netflix considers each service individually.
Any talks or posts that you can share about Netflix and their services? :)
And with Google... They also have the monorepo. I'm curious about how Netflix solve the global change problem. Slack message? 😅
I'm sure Netflix has some common libraries for something as global as logging. I can't imagine each service re-implements every logging detail. I think it's most important to avoid common libraries for your actual business logic.
Awesome video. I really loved the gophers in the PPT :)
Yeah we can abstract everything. But not everybody is Uber. Ask yourself if you really need to. Indirection brings complexity, too.
Also, monorepo is a funny come back of the modular monolithic. In more complicated.
does the tracing example really work like that in practice? How can all services depend on the same configuration and same server? same base server maybe but you’d want to set up your own endpoints in a constructor. And in that case you can just have every service use the same base server implementation and add a tracer for that. No need for dependency injection. Another point, does this really make devs more productive when coding global features? its usually much harder to follow the flow of code with a dependency injection framework as you don’t really know how your object was constructed, and that tends to be important..
It just have many best practices and concepts explained before by people like Uncle Bob and Martin Fowler. I like the way Uber's putting those ideas because they structures it simple . But it's very superficial. They could put more details about their code structure and best practices with monorepo to the community.
Nice to see a real life example at scale.
Great talk. Applicable generally across all programming languages and not just 'Go'.
welcome to 10 yrs ago uber
Awesome, Go with IoC containers back in 2010?
Amazing talk! Should be watched by everyone learning Go.
awesome video
DI was an idea that went horribly wrong. Spring is a pain to troubleshoot. I consider DI to be anti-Go. I sincerely hope Go community does not bring in the mistakes of Java to Go.
What she shown here is not Java's Spring or whatever approach.
Can you elaborate more on why DI is anti pattern with a proper practical example maybe?
@@JohnDoe-ji1zv DI is useful when you actually have multiple implementations of an interface and don’t know which one it will be until runtime. Sadly, DI is often abused and used when there aren’t actually multiple implementations. Seen many cases in my career where developers will use DI for everything regardless of if it really brings a benefit or not.
I thought go development was all about no magic very verbose coding so every thing is clear and no hidden stuff. But this doesn't look like the that. And all this concept looks awfully close to spring framework
interesting ..that’s not what go development is ‘all about’ ..not at all. perhaps it’s my experience alone but i’ve not ever heard it described that way before. never. to me golang is ‘all about’: performance, simplicity and expressiveness ..that’s just me though.
Is it me or do only the people with experience exclusively in Spring framework tend to equate everything else to it? - What's this "kuber--shmoober" thing they keep talking about? - Oh, Kubernetes? It's a container cloud that - Containers? So, another reimplementation of Spring, I see.
They are probably doing Go wrong
@@Frankey2310 haha
Amazing presentation!
Loved this lecture! Thank you so much for sharing it!
The next presentation will be people “invent” decorator in go
SOLID principles at work basically. Great stuff.
I wish I saw this a month ago
💎✨👍
solid talk)
Exceptional presentation!
Thanks!!
Такое ощущение, что по мотивам художественного рассказа написали уголовное дело. Да, мы работали с DI - конференция-то профессиональная. Монорепа на го - тоже мне новости. Вот эту всю шелуху надо было сжать до пары минут, а вот про мелочи реализации всё выступление и пиздеть - прям вот объявления типов из app.go показываешь и детально обосновываешь, почему они такие (со спецификой го, если она есть вообще).
well, one acronym: OSI; one word: layers; ... very basics of any swdev, imho; so I thought that slavery was prohibited in past centuries; nice that you now treat ppl as developers, instead ))
waste of time