Hacker News new | ask | show | jobs
by vasergen 1421 days ago
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.
3 comments

Just 'services' will do. A couple of them tied together with a single front is >> a monolith.
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."

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.

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.
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.
> 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.

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...

> 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.

You mean a Client Server system? That is not microservices.
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.
Why micro-?