In microservice architectures, applications are built and deployed as highly decoupled, focussed services. A decoupled application architecture allows each component to perform its tasks independently - it allows components to remain completely autonomous and unaware of each other. A change in one service shouldn't require a change in the other services. It is the process of separating services so that their functionality is more self-contained.
Easier to maintain code and change implementations
Smaller code blocks are known to be easier to manage and understand. By building your application as multiple connected services, parts of your application can evolve independently and each service can be maintained by separated developer teams. It is easier to read each other's code since you don't have to understand the whole app in order to understand how a small part of your app works.
If you have a decoupled system, where you need to change a component, you can do that as long as the API remains intact. If you want to use a different database backend or structure, you are good to go. You just need to replace that part instead of walking through the whole project looking for references and dependencies to the old service.
Different parts of your app can evolve independently if your architecture is decoupled.
Cross-platform, different languages and technologies
Different application services have different needs. Maybe you would like to implement your solution so that different components are running on different platforms, or are built by different programming languages or technologies. One part of your service might be better suited for Java, while another part might be better suited for Ruby - you are able to choose the right tool for the job. The decoupled nature of the sender and the receiver can help to remove any implementation dependencies between them.
Independent releases
In a monolithic architecture (non decoupled architecture), you might need to deploy the complete application in once, and this might affect critical steps for your service. You do not want the signup process to break or be in-responsive for a while just due to a deploy. It's good to be able to deploy an application's components separately.
How to decouple your application
Decoupling between services could be achieved by simply adding a layer of technical abstraction, like a message queue or a well written interface, between the content producer and the content consumers.
Message queues decouple your processes. All that is required is that the sender and the receiver agree on a common format for messages and their content and that they are using the same message broker. When part of your architecture fails, it doesn’t need to take the entire system down with it. Messages can still be added to the queue and be processed when the system has recovered. If a message fails to be delivered, the message can be redelivered until the message is processed.
Distributed workload and Scalability
A message queue makes it easy to scale up a decoupled application. When the incoming message rate is higher than the consumer rate; you can simply add more workers, receivers, whose job is to work off the queues faster.
If you have a web application, you can let this web application generate messages in response to user inputs. The receivers can retrieve these messages and process them and return a response when it is finished. By doing it this way, the user interface can remain responsive. It is not blocked while the messages are handled asynchronously. Many websites have peak hours, where the activity burst. A large number of website users might suddenly generate a large volume of messages. If you add a message queue in-between the sender and the receiver, the message queue will act like a buffer, and receivers can gradually drain the queue at their own pace and the website visitor will remain a happy visitor.
If you are new to message queueing, I recommend you to read this article about message queuing in general or RabbitMQ for beginners for information about message queueing with RabbitMQ.
Please email us at contact@cloudamqp.com if you have any suggestions, questions or feedback.
