Service oriented architecture has been a buzz word since many years, and rightly so. Its definition? Encapsulate distinct responsibilities into micro service components solving a small set of tasks. One then connects those micro services to a distributed system solving the more complex tasks.
PaaS systems like anynines, simplifying deployment processes, allow us to quickly deploy clusters of micro services wired to database and message queues.
Table of Contents
Benefits of Service Oriented Architecture
Following a service oriented architecture brings a lot of benefits. It enforces better software architecture with a well defined interface for each micro service. As each component is responsible for its distinct specific domain, it encapsulates solutions in small chunks of code which are easy to test and adjust while following an iterative development approach.
Instead of having a big monolythic application handling all problems in one common code base, we can implement many small components to achieve our goals. In addition to that we can reuse those micro services for other projects. In many cases this is possible without any changes to the micro service’s code base. Just deploy a newly configured application instance and integrate it into your “zoo of apps”.
A hands on example
Let’s formulate an exemplary architecture to illustrate a possible distributed system. Mail transmission and user management are common tasks in many web applications. The diagram below demonstrates a service oriented approach implementing those use cases.
The User Service is responsible for managing user accounts (CRUD) and logins. It could implement the oAuth2 protocol and provide a common interface to manage user data interactions.
The Mail Service provides a simple interface to send emails. The request below is an example on how we could implement a Mail Service REST interface.
The Shop and Community Portal web applications access the User and Mail Service as needed. Micro services can be connected using different protocols like REST APIs or message queue systems.
Let’s consider the following use case:
We would like to introduce a reseller portal application into our eco-system. The reseller portal needs to create users, login users and send emails. We can use our already established micro services to achieve these requirements instead of implementing a mailer and user management feature within the new portal. That way we don’t introduce unnecessary redundant database entries which could lead to inconsistencies between the systems.
This approach saves precious developer time and prevents us from implementing the same functionality again and again.
Playground of micro services
PaaS systems like Cloud Foundry allow us to create our own playground of micro services without bugging our beloved admins. We at anynines invite you to cultivate your own zoo of applications.