Comment Re:Decision was not faulty;but design definitely w (Score 1) 118
I agree, and I am a big proponent of service architectures, and yes, I force myself to use the term "microservices" because it seems to be the popular one these days.
There isn't anything new about service architecture. You put a network call in between two pieces of code and suddenly you need a queue for the interface to be robust. Once you put a queue in front of code, you're handling messages, and in particular, you're handling messages that can arrive more than once. So you need to ensure your handlers are idempotent. Then you need to stitch together a reporting database of some kind to serve queries that supply the data for the UI. Which should mean that your services publish events -- pub sub is another pattern that has been around for a while. All of that work wins you the ability to compose a large, complex system out of very loosely coupled, autonomous pieces. When it works, it's great. It usually doesn't, however, because teams don't have the maturity, habits, or expertise on hand to see such a project through to completion.
Nothing about it is "new," except to the inexperienced web programmers I coach who don't really understand service architecture -- who also usually believe that you can achieve microservices just by taking parts of your existing system and putting a web interface around them. Sigh.
All that to say, there are some definite benefits to service architecture that shouldn't be discounted just because "microservices" is yet another tech trend to have been fed through the meme machine.