Do one thing... That's where the trouble starts.

Yeah. Architecture and separation, these are the foundation.

If you don't do these two in a proper and sane way, you most likely end up with the rotten pile of shit most companies call micro services.

Hot glued unmaintainable mess of deprecated shit stapled together by a custom framework abomination cause no one gave a flying fuck to properly design it.

I see these things daily.

I write the reminders every week.

"Hey, lil retarded dev, you don't need that dependency, you can just use languages feature XY added in version XY"

"But that's how I always did it"

Moments where you want to apply violence from the category "inhumane".

Or even more retarded: Yeah it does everything that was written in that one epic that took 6 months with 30 devs to finish.

I sometimes really wonder how some people managed to survive till they got the job. Parents must have been pretty vigilant 24/7...

In reply to atheist in another rant ;)

@atheist

Couldn't resist.

But if you can't get separation right, it doesn't matter if you're running microservices or a monolith, your codebase is still a pile of junk!

Properly separated monolith vs microservice architecture - who wins?

Also which one deals better with changing reqs that mess up your architecture, are incompatible with it, etc.

@hardCoding I think the ideal size of a code base is "whatever can be maintained by a single team". But that means different things in different companies, I've worked on a team that effectively maintained a 100k line code base, and another that struggled to maintain a 10k line code base.

A single team can deal much better with changing requirements. Microservices is one solution to that problem.

@hardCoding

The thing is: microservice is undefined. Before we could argue, we would have to define what a microservice is.

Which is near to impossible because most definitions of a microservice are so “vague” and subjective that they cannot be put into a standard definition.

Which is why I would start at the opposite end - looking at what a microservice *is not*.

Freely available, blog post regarding micro service antipatterns, which is from the author of microservices patterns / manning:

http://chrisrichardson.net/post/...

If you look at the number of antipatterns listed there, it should make immediately "click" that microservices isn't a thing you can't implement without *huge* human resources.

Note: *huge* human resources. We're talking easily about at least 50 developers plus specialists for dev-ops / et cetera.

Plus: To pull it off, all teams must be able to work interdisciplinary.

Which brings me back to the point that microservice is really hard to grok.

If done right, it cannot be done by most companies, as many companies completely and utter lack in that area.

Doesn't mean microservices bad, but it means most companies talking about microservices only *pretend* to use microservices.

Microservice and monolith are two extreme, perverted forms of architecture.

The middle should be the common ground.

Clean separation of domains in architecture,

proper versioning and release system,

minimal dependency with strict policy regarding adding dependencies,

clean responsibility and escalation rules (regarding code -/ code guidelines -/ communication...),

most importantly: devs must own their faults.

No "that could have been done better by someone else" or stuff like that.

@IntrusionCM concerning your last points. And mind you that I agree, but in what unicorn filled universe would such a company exist that microservices could be fully and properly implemented? On every place that I have worked it becomes a complete disaster, mainly due to the one factor that we can never remove from the equation: human stupidity :P

@AleCx04 usually those I don't like working in...

Hierarchical companies with a strong authority and reward system.

Reward system not meant in an all positive way.

I've never worked at FAANG or other companies for that reason, but imho without a form of close monitoring, a strong hive like authority system it's not possible.

Very small teams which are permanently monitored, a project manager that watches 5-10 teams, a very rigid monitoring coupled with CI / CD.

Monitoring largely automated, from VCS activity to working hours to mail analysis.

The reason large companies are successful is because of the reward system.

Be a good worker drone, do as you're told, make it a success - you can enjoy our facilities 24/7 (gym, swimming pool, kindergarten, ...)

Be a bad worker drone and you get fired.

No more rewards.

Reason for the lengthy explanation: I said *a lot of human resources*.

Mostly you need the lot because the simplest form to achieve success is to constantly sieve out anyone who disturbs the hive.

Which is the primary reason I don't like working in such companies - they can sugar coat it as much as they want... I even know a lot of persons who loved working there... but when you look at it from a distance, it's the perfect example of a hive where everyone has to play their role or they will get sorted out.

The same principle applies to microservices imho - if microservice is shit, fire the team, redo it, rinse and repeat till it works perfectly.

It's not a unicorn thing, more a dystopian "George Orwell" thing...

giving linux cli tools as a positive example XD