RabbitMQ is a message broker. Basically, it allows your services to communicate asynchronously with each
So why to choose a microservice architecture in the first place.
Well for a long time, people didn't. Developers leveraged a monolithic architecture which in few terms means a single server (which entails a single technology) for a single application. Which makes a lot of sense and monolithic architecture has the following advantages :
- Easy to manage : when working with a single technology, you'll have your unified linting rules, single dependency manager, single code base and end up with a single application
- Better Performances : calling functions in memory yield much better performances than calling services through network
- Code reuse : having your application in a single programming located in a single project allows to share functions and definitions throughout the application
But nowadays, some developers have started to favor a microservice architecture which in few terms can be explained as creating a separate server for each module/functionality in your application ( thus the name 'micro' service)
Perhaps a photo can be more expressive:
Microservice architecture does come with a cost :
- Hard to manage : Working on separate projects ( each service can be considered as a separate project ) can make dependency management, documentation, deployment and handling different technologies more difficult.
- Degrading in performance : In a perfect world each service will be self sustained and can handle client requests on it's own. But this world is not perfect and your services will most likely have to share some data between them and API calls will not be as fast as in memory function calls
- Duplicate Code : Working with different technologies and programming languages can make it difficult to share code
- Resources Overhead: Guess what, each of your services will be a separate instance. Meaning if you're using nodejs, you'll need as many instances of nodejs as your services which costs in memory and CPU
But even so, developers are still willing to pay this cost to achieve:
- Freedom to mix and switch technologies : With the code base divided between modules and servers, developers can use the technologies they feel most comfortable with and most suitable to the task. There is a library that solves this problem that we have but it's written in this new and weird programming language . Sure make a service around this library and let someone good with weird languages handle it.
- No Single Point of failure : Usually if some bug escapes testing and an exceptions is kept uncaught it can bring the hole system down. But with the modules of the platform divided between multiple services, the damage will be limited (if things are done right) to that service and rolling back a previous version or monkey patching the bug is a lot easier.
- Scalability : What to do when you projects takes off and suddenly you need to handle thousands of users and multiple requests per seconds. Well in monolithic applications you'd probably well off buying a stronger hardware and in time this will get costly. Duplicating instances of the platform is also a solution. But mostly you don't need to duplicate the hole thing, usually it's just a few modules that eat up most of the resources. It would be far more beneficial and cost effective to duplicate instances of just those services and we can even scale up and down dynamically when your project is divided as series of services that join and leave the application.
- Reusability : Modules that handle user authentication, file uploads and CRUD requests do probably exists in most applications. Wouldn't be fun to have multiple services that you spin up when you need certain functionality to exist and improvements in one service will benefit multiple projects.
These are some of the benefits of micro-service architecture and why it increases in popularity. In the next articles we will visit tools that tackle the complexity of implementing such an architecture.