Top 5 techniques for building the worst microservice system ever - William Brander - NDC London 2023

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