Комментарии:
I also prefer monoliths because nothing says job security as maintaining a code base that multiple teams work on it, new devs just hack it, tests contain static mocking & mocking & homebaked solutions, updating frameworks just take ages, we can't update DB connection manager no one wants to take responsibility, you can play security vulnerability bingo, can solve issues by just throwing more CPU and RAM on it, deployment of a new version is more eloquent than a masonic ritual, you need to become Dev Lvl 33 to know the meaning of all 267 tables in the database.
I'm only half joking, even if the talk has nice points, every solution comes with its own can of worms
Excellent stuff, with a great humor :)
ОтветитьHe exactly described what all of the smartest guys in our company designed...
ОтветитьFor those that work in the Java World, I recommend looking into OSGi, this is a framework that will solve the Monolith vs microsoervice concepts where you have full modularity in a monolith with full individual deployments live in a running platform, it is built upon the services concept and interface way of thinking as descibed in the end of this talk. Full speed in one machine.
Ответитьw00t anti patt0rn
ОтветитьFYI...India doesnt have slaves
ОтветитьThere is one more option where a rewrite is probably a good idea, when the current one is built on a platform that is going to die and you either just shut it down or replace it, and you cannot just shut it down since its vital for the business.
ОтветитьThis guy is incredible. Great job!
ОтветитьIn the end, his ideas are even worse than the worst patterns. Coupling on code / library level instead of events... but if it works for you, fine. In the end, Microservices, Monoliths, Libraries... They all work and all suck, just in different ways.
ОтветитьThe Search Engine today is typically some kind of highly optimized product, e.g. Elasticsearch. You need to feed it with data, so you end up with some kind of data transfer with Kafka or something. But then the Search Engine can search flexible, quickly and independently. The engine pattern is useless here - just think of integrating a SAP engine there. :)
Ответитьhe doesn't look South African,
ОтветитьWhen you have 6 dependencies and each have a latency of 200-1200ms...
ОтветитьThis is why companies should just buy an off the shelf solution that already works. Ok... if an off the shelf solution doesn't exist then programmers should create their own company and create and market such solutions. More fun than working for a dead end employer.
ОтветитьThis was supremely relatable
ОтветитьKnowing how accurate he is, is causing me stress. lol
ОтветитьI've never written a bad system - everything I've written was the best thing I've made for that time!
ОтветитьLooks like everybody forget this great advertising where people build airplaine in the air. No need for Stable Diffusion
Ответитьbad system: starting with microservices. A monolith will do the job for 99% of the apps
ОтветитьThat was very sad to realize: it is exactly what we have in our company
ОтветитьThis was great, now we need the complementary talk about building the best distributed system ever.
Ответитьthis guy seems like he'd be a hoot to have as a coworker. good jokester who knows how to satire while making great points
ОтветитьI don't think rewriting from scratch is always a bad thing. There are certain times when it makes sense; for me it depends on the level of complexity and familiarity.
- If it's not a complicated system, then writing your own is relatively easy and can help you discover new ways to architect it.
- Or, if the project has just been handed to you and you're tasked with maintaining/updating it, you will probably spend as much time learning the system as you would rewriting it (and you can do both at the same time! Use the old code as a reference)
I've been in both of those situations before and have successfully managed rewrites in both cases. There are also some cases where I started a completely new codebase and eventually ported the developments back to the production code. Having a clean slate gives you agility, a freedom to experiment, which is more productive for some people (myself included)
I like the verb/noun distinction - not quite functional vs object-oriented but close. By "engine" do you mean distributing a shared code-base, as you describe logically identical physically separate?
ОтветитьYep this pretty much happened at our company :D We are currently undoing the microservice projects of our architects, moving them back into the monolith.
ОтветитьAwesome lecture 🎉
ОтветитьI think I don't want to work in this field anymore :) 🤯🔫
ОтветитьThis dude absolutely nailed it lmfao waaaaay too relatable
Ответитьbest title ever
ОтветитьWell, I do agree with the take on monoliths. Like that Indian Monolith, they can be beautiful. But also like that one, they can be useless and get to be abandoned.
ОтветитьThis guy hammer the nail badly on every problem I encountered working in big system microservice environment. Ouch.
ОтветитьThe fun thing about consulting is I've gazed into each of these abysses lol
ОтветитьHow do you know the slaves did not claw the rock away to build that temple? I've clawed the keys away from board for 13 years!
ОтветитьScary accurate. I guess the problem is always the hype train, when a new trend comes along previous models are always considered as trash and then everyone tries to cram everything into a new model without considering what makes sense and what dosent.
ОтветитьDid he reinvent the JAVA application server?
ОтветитьMicroservices is top 1 worst technique.
ОтветитьNot surprised by this talk. Just as Udi mostly dedicates his talks to shit can anything not NServiceBus friendly, his co workers are no different.
Ответитьpayment systems have error msgs which u can parse through. why dont give an actuall example uve encountered when speaking on a conference and putting it out there?
this is failed stand up for programming. zero of actual knowledge in the lecture part mixed with not even luke warm jokes.
'heh, programming sux. am i right fellas?' good one. thx for that. rly worth the time investment.
The guy is funny as hell and I enjoyed watching it for this reason. He has a talent of a standup comedian. However his comedy style is that of a very nihilistic pessimistic cynical etc so in the end a bit too bitter.
On the negative side, he is really bad at making arguments. The only argument he gives why big bang rewrite won't work is his own experience that they just won't. "Trust me i'm a developer and we're really bad at giving estimates". The rest of the story is just his single negative experience and that is certainly not the only option. Same thing at Search engines - he constantly calls the software design "your cool stuff" as to make fun of it and consider it detached from reality by default. This is another arbitrary assumption and he doesn't go into the matter of a thing, just tries to be funny and I think the audience showed a little disappointment too (also read the comments to the video). This is just a funny rant, not a serious software discussion, sorry guys.
If your entire project consists out of independent modules that only interact with each other through well defined interfaces, there is no need to ever rewrite the whole thing at once. You can always rewrite a single module without having to touch any other module in the process and once done, you just swap the old for the new module. Even if you need to alter the interface, as the new module will require a different interface, your rewrite is still limited to the modules that use this specific interface, which will probably be multiple modules but still only a smaller subset of all modules. And even if you need to change the way how certain modules interact or you want to combine three modules into one or split one module into three, this still limits your rewrite to a group of modules affected by it. So at all times you are only working at a subpart of the system, keeping the rest of the system just as it is, yet if you keep going and going, eventually you will have rewritten the entire system at some point, just never as a whole.
And by modules I don't mean micro services, by modules I mean a bunch of code grouped together. Of course, you can distribute modules into different processes or to different containers or to different machines or to different data centers but that's something the code shouldn't need to care for. The code only knows the interface of a module and it will use that interface to get access to any data it requires or request any action to be performed that it wants to be done. Whether this will just call a function in the current process, send a request via RPC to another process, send a request to a micro service or calls a REST API on a server at the other end of the world is non of the code's business and subject to change on a daily basis.
I loved his "imagine the result using Scrum" when showing the Indian monument....
ОтветитьThis is an excellent talk. Worth referring back to. But I really wish it wasn't presented in its negative. I get it was done for humor, and it works in that sense, but it really makes you do mental gymnastics when you try to refer back to a specific part...
Ответитьwho is really bad as estimating, must be a really good developer :))) that was funny and I also agree :))
Ответитьwrite everything in main like a real man
ОтветитьCame across this talk today. Really good design pattern for cross-domain CRUD operations.
ОтветитьGot one more situation where a rewrite works: When the original was written in a hackathon five years ago and then, stupidly, was maintained without being updated
Ответить