Monolithic vs Microservice Architecture?
This video starts off by explaining that you may build all your functionality into one application/system, often referred to as a monolith. But this approach has several downsides because all functionality becomes highly coupled. So if your application is under heavy load, for example, the entire application will suffer.
A better way is to divide the app and its functionality into different microservices that runs on their own, completely separated from each other. This "Microservice Architecture" comes with a lot of benefits as explained in this video. We are looking at better performance, easier maintenance, higher security, and reliability etc. Yet, the different services still need to communicate with each other in a reliable fashion. For this, we need a Message Queue as a middle man/broker.
What is the benefit of a Microservice Architecture over a Monolithic Architecture? As an example, we will look at the same application (a fictive photo ranking application) built in both architectures. This is the easiest way possible to highlight the differences and explain the advantages between the two.
Check out our YouTube channel for more videos
You will find this video and more on the CloudAMQP YouTube channel. Stay tuned for more informative videos on RabbitMQ from the experts at CloudAMQP. As always, we love hearing from you with suggestions, questions, or feedback!
Excerpt: Microservices and Message Queues - Explained
When I left university about ten years ago I had never heard about Microservices or Message Queueing. Today at CloudAMQP our architecture is completely built upon small microservices communicating through Message Queues.
Over the last few years, we have successfully made it easier for developers to move into a Microservice Architecture. And that is what we will talk about in this video.
Let's follow an example: I want to build a photo ranking application that allows users to upload photos, and have them ranked by other users.
Monolithic Architecture
My first plan was to build everything into one big application. A structure often referred to as a monolith, with a front-end handling interactions from users - including the ranking and the uploading of a photo. The photo is then scaled and stored by the backend which also handles authentication and ranking.
Monoliths communicate within the system since all parts are running in the same process. And this system is highly coupled, as every function is reliant on the others.
Microservice Architecture - divide and conquer
Now imagine that I choose a Microservice Architecture instead. The application is divided into two or more small services, where each microservice is developed separately.
The finished application is the sum of its microservices. With the frontend handling user interactions, just like the monolithic application. Unlike a highly coupled system, however, the rest of the app is divided into specific services.
One for photo-scaling another for ranking of photos and a third for authentication, and so on. In order for this to work our microservices need a way to communicate with each other. To make sure that the data is delivered in a reliable fashion between the services.
Using a Message Queue to manage communication
And to make sure to not lose data in case of system failure, we need to centralize the management of the data. The solution is to send the data as a message and to use a Message Queue as a broker. Messaging or Message Queueing is a service-to-service communication allowing one service to communicate with another service by sending messages to each other.
For example, one service puts a photo scaling message on a pre-defined queue. Another service - the photo scaling service - retrieves the message from the queue, and processes the photo.
After a few weeks on the market, my app becomes highly popular. And thanks to the Microservice Architecture the application can now manage multiple heavy photo-scaling tasks per second. I can also, easily, connect more photo scaling services when my application is under heavy load.
So another feature is now requested, users wants to be able to add filters to the photos. I hire a consultant that writes a Photo Filter Service that connects to the rest of the application.
Due to the Microservice Architecture, it's now easy to make changes in the system and maintain written code. I can work on the scaling feature while the new consultant can work on a different service at the same time.
The consultant can add code to the Photo Filter Service and test it without having to worry about disrupting any other functionalities. And the new service can also be written in any chosen language.
This highlights another obvious advantage of a Message Queue. The ability to isolate a fault to a single service. For example, if our Ranking Service is down. Our Photo Scaling Service, Payment Service, and Authentication will still be up. Ensuring that users can still use the app even when they aren't able to rank a photo for a short time.
Benefits of using a Microservice Architecture and Message Queue
Let's go over what we have just learned...
- We built a system with low coupling, as no service needs to know about other services.
- Development and maintenance were easy to do, since different developers could work on different services at the same time.
- Different services could be written in different languages.
- Fault isolation was achieved, the complete app was not down just because of a single failure in one service of the system.
- And finally: we have built a highly scalable application. If one part of the system is under heavy load, the queue can grow. And if it's growing a lot we can just add more services that can consume from the queue.
If you would like more information, please visit our beginner blog series: RabbitMQ for beginners. We also have a Free Ebook: "The Optimal RabbitMQ Guide" available to download - covering Microservices, Message Queueing and RabbitMQ.
