[revskill]

Microservice is to manage junior level programmers who don't know how to make loosely coupling architecture. That's it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic.

Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff

[tomtheelder]

Firmly disagree. Microservices get you very little in terms of code quality enforcement past what you would get with a well modularized monolith, and they introduce a lot of code quality & architectural pitfalls. I think going microservices to enforce boundaries and decoupling is a very bad idea that will create far more trouble than its worth. I'd be a lot more scared of my junior devs committing code to microservices than to a decently organized monolith.

I would only seriously consider a move to microservices for deployment/perf reasons.

[revskill]

You might misunderstand the point here.

It's about how to keep the velocity without firing junior dev, without removing bad code from the production system.

So microservice is a leadership tool to manage it. Keep it in control.

[vasergen]

Micro-services also good when an organization has a numbers of teams with different domains and release cycles, at some point it would be easier to spit code in some ways and have a boundaries. In this case splitting to services/micro-services creates those boundaries on a network level.

[jacquesm]

Just 'services' will do. A couple of them tied together with a single front is >> a monolith.

[foobarian]

I find it pretty entertaining how the word "microservices" got to mean what we used to mean by "services" or "web services." It has not referred to size in the npm "left-pad" sense at all for a long time now.

I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."

[dkarl]

I think there's a lot of historical accident involved. Personally, my experience of the two terms was that I heard about "services" aka "SOA" first, and it meant a top-down global architecture where the pieces were composed in elaborate, cumbersome ways: service buses, orchestrators, complicated XML-based technologies, service discovery, remote transactions, all that fancy stuff that many people tried and few people ever got working correctly. People were talking about integrating a new service to your architecture by dragging and dropping widgets in an orchestration dashboard generated from XML descriptors published by the services, and it was the kind of thing that blew your mind for a few seconds until you realized it was obviously never going to work.

Then I heard about "microservices," and the people using that term were talking about JSON and HTTP and DNS, stuff you could actually imagine working, and then you tried it and you actually could get it working with almost no effort, which was mind-blowing in a different and better way.

That difference was a historical accident based on where those terms were in the hype cycle. Now a lot of definitions of "microservices" describe architectures that are almost as elaborate as the old SOA ideas I was exposed to, and people have the same reaction I did to "services" back then. And now it's the supposed microservices experts who will tell you that if you did anything simple enough that you actually got it working in less than six months with less than fifty people, then you did it wrong and doomed your company. The hype cycle has made a complete turn.

[jacquesm]

This kind of thing happens a lot in IT. You could see the same thing around 'Agile', '4th generation languages', 'mindfullness' and a whole raft of other terms that momentarily become the fuel for the incomestream of certain consultants.

[jacquesm]

When I see a service around every single table in a database with an absolutely ridiculous spaghetti of inter-process communication to tie it all together it usually is because someone took the 'services' pattern a bit too far and in that case 'microservices' is a proper moniker. And for Erlang based systems it usually is also appropriate. If there are fewer than 10 or so services usually they are not 'microservices' but just services.

[foobarian]

> a service around every single table in a database with an absolutely ridiculous spaghetti of inter-process communication to tie it all together

For what it's worth, I suddenly feel a lot better about my employer's architecture. :-) But we still call them microservices because language.

[jacquesm]

There was this fantastic cartoon in a dutch newspaper long ago, it was a really long train about to leave the station and lots of people were trying to get on it, by hook or by crook, people hanging on to windows, sitting on the buffers etc. A reporter with a microphone approaches one of the people trying to get on the train. "Sir, why are you trying to board the train, where are you going?". The answer "I have no idea but I really don't want to miss it.".

The banner on the train was 'The Internet', the cartoon was published in 1995, right when the dot com bubble started its proper inflationary phase.

These hype-trains occur over and over again around a specific theme, the funny thing is that 'the internet' eventually became at least as revolutionary as those that were trying to board that train hoped it would be. But the bulk of those hyped things are usually not going to make such a huge difference and then, instead of adopting the item and incorporating it we move on.

You can usually get an idea after a year or two when a technology is introduced which way it will go, and a good sign that the life is out of it is when the consultants and writers of books move on to greener pastures.

See also: blockchain, the semantic web, etc, etc...

[allendoerfer]

> I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."

I know you are referring to something else, but it actually means that the battle is won.

[jnash]

You mean a Client Server system? That is not microservices.

[jnash]

There is this much simpler advanced technology that can be used instead that has been around for 50+ years: it's called libraries/modules. It works. Linux is a collection of thousands of libraries. Windows is a collection of thousands of libraries as well. Linux and Windows are way bigger than pretty much any other software out there. So I am sure this advanced technology is good enough to handle whatever you and most other devs are working on.

[mirekrusin]

Why micro-?

[throwaway894345]

Code quality is only one reason to use microservices; deployment frequency is another (you want people to be able to deploy their service without needing to coordinate with every other service in the system).

Moreover, code quality isn't just encumbered by junior devs--in fact, in my experience it's more often managers pressuring developers to take shortcuts (e.g., taking a dependency on another system's private internals in the name of expedience, while swearing up and down that we will totally clean it up in a future iteration) or other organizational hurdles that make it difficult/impossible to fix it the right way, so shortcuts are taken instead (with microservices, the organization has to confront those issues, they can't be easily papered over by bypassing official interfaces).

Another reason to prefer microservices is security--not putting every secret in a single process's memory space is a great way to minimize blast radius if a service is compromised.

Another reason is reliability--if one system has a catastrophic failure mode, it won't take out all other systems. Of course, if the failing system is a core service, then it may not matter, but at least you're not bringing everything down when some service on the architectural periphery goes haywire.

[jnash]

Nothing you say can't be accomplished by using libraries instead. The largest software on earth (Linux/Windows/...) is created by composing thousands of libraries into a single system. With thousands of developers contributing from all over the world. It works. It's proven.

[throwaway894345]

Composing libraries offers some of the advantages of microservices, but not all of them. For example, a vulnerable library still has access to all of the secrets used by any other library, whereas a vulnerable microservice will only yield the secrets it needs. Similarly, a critical bug in one library can bring the whole process down, even if the library itself is a non-critical component—a critical bug in a microservice will only tank that service (and maybe services that depend on it if they don’t degrade gracefully). Notably, Linux and Windows spend tremendous energy making sure these vulnerabilities and bugs don’t slip through!

[msaspence]

I love the idea of "managing junior level programmers who don't know how to make loosely coupling architecture" as describing engineering leadership, regardless of how cynical it is.

I do question how microservices manage that, though? Tightly coupled microservices ie "the distributed monolith", are a still real danger for teams that don't have enough engineers that know "know how to make loosely coupling architecture"

[revskill]

Yes, we have a term for that: Technical debts!

The reality is like this: You have a critical system that ran for ages, and now what will you do to scale the features ? By allowing/teaching junior devs to understand how to contribute to the codebase ?

There's a simpler way to do that efficiently: Extract a subdomain into its own microservice and you control the interface. Then even that microservice has bad code quality (tech debt), your business is still running fine!

Problem solved.

[ripberge]

Adding in a machine boundary does not guarantee loose coupling. If a dev does not have the skills to make a loosely coupled monolith, how they can they suddenly have the skills to make a collection of loosely coupled services running on more machines? That same low skilled dev is going to have to deal with a lot of other complexities now...

[revskill]

The point is, to keep the sprint in velocity, let's just keep the bad code (tech debt), but make sure it won't break the quality of original system. By extracting "bad parts" into its own system, you can manage it efficiently.

[awinder]

I would think that junior level developers are usually walking into an architecture put together by leads/seniors? Juniors should be coming into a well-architected monolith that they can be productive in, if they can’t that’s kinda on the senior staff…

[jnash]

I have 15+ years of management experience and I have never ever had a problem managing developers at all skill level. You can't solve management issues with technology. You solve it with people skills. I sincerely hope you are not and have never been a manager. There are already enough arrogant and incompetent managers out there.