[torcete]

I never worked with micro services, but I have this question. Do micro services require more and better management?

I can imagine that you need to keep track of all these services, along with information about dependencies, code version, API version and others.

Of course, monolithic services also require these this sort of management, but it should be less complex.

[jedberg]

The short answer is yes. The longer answer is that you will spend a bunch of engineering time on building systems to help manage these things, but if you do it well and you're at a large enough scale, the investment pays off.

Some companies spend a bunch of engineering time making their monolith easier to manage (Google/Facebook) and some spend it making microservices work (Netflix/Amazon). Neither one is better, just different paths.

Where you get into trouble is trying to go either route without spending the resources to make management better.

> I can imagine that you need to keep track of all these services, along with information about dependencies, code version, API version and others.

This is the software Netflix wrote to do that:

https://github.com/Netflix/eureka

[paulddraper]

> making their monolith easier to manage (Google/Facebook)

Google has Borg.

They literally invented Kubernetees to make their microservices easier to manage.

---

Don't confuse mono/microservices with mono/micro repositories.

[jedberg]

I'm aware of that. I was talking about their modified version of Subversion.

[paulddraper]

Right. Google has microservices, in a monorepo.

[gorjusborg]

The whole microservices thing is a little crazy.

Someone just looked at what devs came to realize worked well, slapped a name on it and it blew up as a hot thing.

Since then, I've seen so much wrong done in the name of 'microservices'. It shouldn't be some aspirational goal to work with them.

Also, the fact that the word 'micro' is in the name makes the cargo culters split atoms to reach some tiny nirvana. The size isn't the point. The real point is in having the system/component boundaries closely match the problem domain, and that a single group 'maintains' it.

[Scubabear68]

The “micro” moniker is very unfortunate. I have seen architectures where endless strings of lambdas are strung together like function calls, with the developer not realizing or caring that each is a process, and each call is a network call. Literally one service per function, with the completely expected result of horrible performance and high error rates.

They should’ve been called domain services or something.

[ponector]

After few years of development, current project has around 30 microservises which are dependent on each other, communicate through Kafka and have individual mongo databases each with lots of data duplication.

We call it distributed monolith. It has the worst things of the both architectures.

[pgoggijr]

At Netflix scale, there most certainly is a service discovery registry where each service registers itself. The registry can be used for other services to find out how to reach each service, what regions those services are deployed in, how many instances of each service there are, what operations that service supports, etc.

https://devopscube.com/service-discovery-explained/

[ludovicianul]

They have Zuul: https://github.com/Netflix/zuul and Eureka: https://github.com/Netflix/eureka

[no_wizard]

In many ways, micro services are an engineering solution to a management problem, which is: how do we keep feature teams etc. unblocked and constantly deploying without stepping on each other?

Some famous (Google, Meta, Microsoft IIRC) went into the "one repo to rule them all" approach, with requisite tooling, culture, and expectations to enforce that.

Netflix, Amazon (and I suspect a great deal others) went the micro services route.

As far as I can tell, its about whether or not you can reasonably maintain a good mono-culture around development practices and tooling or not ends up being the main question.

Now, there are aspects of micro services that cross these boundaries, but I strongly believe based on my industry observations that this is where it grew out of. If you think about how these organizations approach developing software it can give you a pretty good idea of why they ended up where they did on this frontier.

[frfl]

You may find this video interesting, https://www.youtube.com/watch?v=5IUj1EZwpJY It's about Conway's Law. I think that's worth looking into based on your question. You can look it up on Wikipedia if you don't wanna watch the video and would rather read about it.