Imagine a simple service architecture setup: single server where I have one service acting as a REST API (PHP), another service for rendering frontend (nodejs), and maybe a database service.
They all communicate through localhost requests, so for example frontend gets data from API by calling http://localhost:{API PORT}/v1/products. Now the request flow would be frontend -> rest api -> database -> rest api -> frontend -> response to client.
Is there a performance penalty when using this approach vs using one monolithic application, where everything is together? Or is it better to utilize something like RabbitMQ for this kind of setup?
1
Any form of abstraction has performance penalty. For instance, the HTTP requests between different layers would cost you a few micro- or milliseconds every time. The question you should ask yourself is rather how important are those microseconds of runtime compared to the eventual benefit you get from micro-services (or a simple multitier architecture). Is it worth it?
Usually, larger applications which are expected to scale are better candidates for micro-services. Small applications which don’t need to scale quickly across multiple servers fit better in a monolithic model (monolithic here means a single application and a database; this doesn’t prevent you from setting proper multitier architecture!)
1
There is some overhead in calling services on the same server, but its not huge. Any performance problems that you would face would be related to poor logic in one of the layers, or the server is being taxed by the combined weight of all the processes.
The ease to allow the system to expand generally outweighs the minor overhead costs at the single server level. Also its good practice to build apps in this manor, because it is a common way for enterprise apps to be architected and being familiar with it is good for employment opportunities.
Why not build out a few simple services that communicate in a chain to test it out? The big thing you’d want to test is how many users it can support before it starts to get bogged down.
I personally think that tripling the http traffic on a single server is a bigger performance penalty than a lot of people may think, but it comes down to what your SLA is and whether the architecture meets it. If this is users making web requests to view a web page, chances are it will meet SLA for a pretty high user load. If this is an automated service making thousands of requests in a short amount of time, chances are much better that it’ll become a bottleneck before other layers. But chances are also high that you can then toss it into a web farm and remove that bottleneck with basically no additional effort, too.