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

This talk was recorded at NDC London. #ndclondon #ndcconferences #microservices #architecture #softwaredeveloper

Attend the next NDC conference near you:

Subscribe to our YouTube channel and learn every day:

Microservices come with promises of scalability, reliability, and autonomy. But if everything is so rosy, how come the only success stories we hear about are at places like Netflix or Uber? I've spent countless hours working on all kinds of microservice systems to come up with the definitive top 5 tips to ensure your microservices become complete disasters. Join me on a tour of insanity through some of the worst ways to make distributed mistakes.

Check out our new channel:
NDC Clips:
@ndcclips

[QuadringentiViginti]

Great material and it is sad that the crowd is absolutely dead. This man deserves a better audience.

[davewx]

As somebody who is currently spending a lot of time maintaining a monolith application written in WinForms, I have to say, I think I would happily jump into the rewrite pit even if it's a horrible decision.

[dazraf]

I've done distributed systems for thirty years. Debugged a lot of bad systems. He's absolutely spot on. I would have liked real performance graphs.

[rns]

I work on ERP system from a very famous European company.
And They provided solution which integrates their own cloud systems to their own on prem system.
I have to say - they ticked every single problem on all of the distributed system architecture. And they are proud of it when we raise issue with the company on these issues.
The integrations are so badly maintained, half of the time you dont get all the necessary data, and half of the time, you want to do customization to make that happen you lose support to their standard product updates.
Good to see it's industry wise practice to make systems worse by introducing more systems in architecture and not just in this company's particular product.

[vikramkrishnan]

As an old fart in this industry I have found that 9 times out of ten using caches and queues before you distribute solves the scaling problem more effectively. Cache your db read operations and queue your writes. Also relax foreign key constraints, reduce the number of indices to ones you really need. And see if you can can denormalize tables particularly those that are used to store "time series-y" data. Also, pre-compute stuff if you can.

[andrewcampbell]

This was great, now we need the complementary talk about building the best distributed system ever.

[tactileslut]

This was fun. Thank you for writing and presenting.

[pavelyeremenko]

So with this dll sharing now you need to monitor all the systems that decided to use your dll/you decided they now have to use your dll and whenever you need to update something, you have to roll out all the dependents.
And if that is not enough to disabuse you of this idea, what do you do if you're a search engine service maintainer and one of the dlls you're importing starts failing? Do you roll it back? What if the database behind it is already changed?
Now you can't really have any responsibility separation in your company in between any services once they decide to share their dlls.

Good thing it's in the talk name after all...

[trurgfn]

So .dll sharing was the secret 6th technique to complete the worst system ever?

[jimmiejohnsson]

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.

[pegr]

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.

[davidmartensson]

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.

[fraschholz]

I loved his "imagine the result using Scrum" when showing the Indian monument....

[mcspud]

The Engine Pattern - going from shipping data across a network to shipping binaries across it instead. Much simpler.

[kcfooq]

Maybe it is time for relational databases

[Carlos-yjon]

fantastic talk, I have worked on real projects that had the same issues as described here. A lot of newbies that follow trends without actually analyzing pros/cons will continue failing on the trap.

[desaihiren]

One of the major challenges with the solution is scaling .. How do you scale the system?
In the example, even though the Product and Search Engine are two separate services scalable (they are logically separate but not physically). Scaling Search service mean, you are scaling part of product service as well (of course only search related).

[RyanLynch]

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

[verybrd]

He exactly described what all of the smartest guys in our company designed...

[pirateonmeleeisland]

This is my new mentor. Every developer / IT person should watch it.