Going from monolith to microservices
You probably have a good idea of the differences between these two types of system architectures but as a reminder, let’s look at the main differences:
Monolithic architecture is often large, complex, and tightly coupled, with the entire functionality contained in a single system. This kind of architecture comes with several downsides, the first of which is that it is difficult to maintain. Making small changes to a monolith architecture may affect the whole system, which can cause a range of issues. Going for a microservice architecture instead solves this by separating functionality into standalone components. Which makes it easier to add, change, or remove functionality without affecting other parts of the architecture.
For example; if an online shopping store suddenly fails to send out receipts via email. Maybe the process responsible for this task crashes, then it will not cause trouble in other parts of the system. Tasks/messages sent to the microservice "send email receipt" will simply be put on the queue until the microservice is back online, and the rest of the store can continue operating as usual the entire time.
Watch this to learn more: "Video: Microservices and Message Queues - Explained"
What are the benefits of microservices?
A microservices architecture makes it easy for businesses to scale and maintain their application. Development, testing, and updates of individual parts can be done continuously and separatly. A Microservice Architecture is attractive to many different industries and organizations since it allows for a more agile approach to software development and maintenance.
What is a Microservice?
An individual microservice is a service that usually exists only for a single purpose, is self-contained and independent of other instances and services. When building an application in a microservice architectural style, the approach is to develop a single application consisting of two or more small services (microservices). Each microservice is developed separately, and the finished application is the sum of all the microservices.
How are microservices connected?
Microservices or modules are decoupled from each other but still able to communicate. Cross dependencies are typical for a microservice architecture, meaning no single service can perform without getting help from other services. There are different ways to interconnect microservices, such as:
- Brokers (eg. RabbitMQ)
- Remote Prodecure Calls (RPC)
- REST APIS
Read on as we dive deeper into brokers, message queuing, and RabbitMQ as an option for your microservice application.
What is Message Queueing?
The use of Message Queues provides a way for parts of the application to push messages to a queue asynchronously and ensure they are delivered to the correct destination. To implement message queuing, a message broker like RabbitMQ is a good option. The message broker provides temporary message storage when the receiving service is busy or disconnected.
Handling communication with brokers
A message broker acts as a middleman for the microservices, receiving messages from one application (producers) and handing them over to others (consumers) to do the job. For example; with RabbitMQ message broker, messages are not published directly to a queue. Instead, the producer sends a message to an exchange. The job of an exchange is to accept messages from the producer applications and route them to the correct message queues. The messages stay in the queue until the consumer handles them and removes them.
There are a couple of different message brokers to choose from. When choosing between brokers, you should try to nail down your requirements. RabbitMQ and Apache Kafka are two open-source message brokers, and you can read about the main difference between them in this comparison: "When to use RabbitMQ or Apache Kafka".
RabbitMQ as the broker in a Microservices Architecture
RabbitMQ enables asynchronous processing, meaning that it allows you to put a message in a queue without processing it immediately. RabbitMQ is therefore ideal for long-running tasks or blocking tasks, allowing web servers to respond quickly to requests instead of being forced to perform computationally intensive tasks on the spot. RabbitMQ simply stores messages and passes them to consumers when ready.
- RabbitMQ is a reliable open source message broker. It has been on the market since 2007 and became a part of Pivotal software 2013. It's continuously updated and improved upon. RabbitMQ has a strong community and highly active core team that produce additional features, improvements and handy plugins. The license of RabbitMQ has never changed (Nov 2019).
- RabbitMQ supports several standardized protocols such as AMQP, MQTT, STOMP, etc. where it natively implements AMQP 0.9.1. The ability of RabbitMQ to support different standardized message protocols means that it can be used in many different scenarios and it allows you to replace your RabbitMQ broker with any AMQP based broker.
- RabbitMQ is used by a large number of companies within various industries and is used and trusted by large companies (Zalando, WeWork, Wunderlist, Bloomberg, and more). All relying on a microservice based architecture.
- RabbitMQ is user-friendly, and by following these RabbitMQ best practices, it is easy to tweak the configurations to suit the intended purpose. RabbitMQ is written in Erlang and is the world’s most deployed open-source message broker, meaning that it’s a well-tested, robust broker.
- The RabbitMQ broker is scalable and flexible. Your team only needs to maintain the producers and the consumers sending and receiveing messages to/from the queue. Under heavy load, if the queue grows larger, the standard reaction is to add more consumers and parallelize the work. This is a simple and effective method of scaling.
Scaling with RabbitMQ
If messages are being delivered to the queue at a faster pace than the consumers can handle them, the queue will just continue to grow. Fortunately, scaling can be done in two ways. You can easily add or remove consumers. You can also allow the broker to scale (add more resources through CPU/disk/memory), to be able to handle more messages in the queue. But remember that RabbitMQ works fastest with short queues.
Summary - so, why use RabbitMQ?
If you’re looking for a versatile and reliable message broker, RabbitMQ is a good option. The RabbitMQ community is strong and growing and you can find a lot of documentation and support. Below is a video showing different RabbitMQ use cases.
If you are interested in trying RabbitMQ, CloudAMQP is a cloud-hosted service for RabbitMQ and offers fully managed instances. To get started, sign up with a free plan here.
