Microservices in Practice: Design and Overview of ludotheca-share-mesh

Github Repo: https://github.com/marco13-moo/ludotheca-share-mesh

Design

Design of the Microservices-based Resource Sharing System

As the system is to adhere to a microservices architectural style, various patterns and decisions were to be followed and implemented to meet the criteria set out by Fowler and Lewis [4]. Such criteria is defined within the context overview. The resource-sharing system also aimed to meet the architectural characteristics as defined within the requirements specification. Furthermore, the system should be designed in such a way as to meet functional and non-functional requirements that do not fall under the characteristics of microservices or distributed architectures, but rather are specific to the resource-sharing system built.

Overview of the Resource Sharing System

The resource-sharing system is scoped as a book lending application:

• Users register themselves with their name, surname and email-address.

• Users can search, delete and add members.

• Users may also check if members have loans out on their names.

• Users may add (provided a valid memberID) and delete books (provided the book is not checked out).

• Users can list all books in the database, find books by title, author, publisher etc.

• They may query and update book availability as well as view an owner’s book collection given their unique ID.

• Users may checkout or return items, they may search for loans given a checkout or return date.

• Additional search queries include loans by: itemID, borrowerID and item type.

• Other queries include listing all outstanding and returned loans.

• The user interacts with the application through REST end-points using the web browser or terminal.

• Input via POST, DELETE or PUT verbs is to be in JSON.

• Responses may be sole HTTP response codes or may have additional JSON payloads including content such as an entity list.

Overview of the Microservices Architecture for the Resource Sharing Application

The system adheres to a microservices architecture style:

• The architecture decomposes the system into book, member, and loan microservices.

• Communication takes place following REST request/response style interactions with a unified API set.

• Clients may interact with the end-points by stating the IP, port, service noun, followed by a path variable, service verb, both or vice versa.

• They may interact with each service individually if a service port number is known and the IP is exposed.

• As the project explored various architectural patterns, the finalized system was branched into two versions (Both employ the same business logic functionality but differ in regards to service discovery):

  • A version that employed service discovery with Eureka

  • A version that employed service discovery with Kubernetes

• If the gateway service is running, all interaction may be executed using only the gateway’s known IP and port number.

• If deployed as containers via Kubernetes, either Netflix Eureka service discovery or Kubernetes service discovery may be leveraged.

• If deployed on a local machine with no containerization, only Netflix Eureka service discovery may be leveraged.

• The databases for each service can be unique and for the scope of this project, choices between a localhost MySQL server, H2 in-memory datastore or a MySQL database hosted in the cloud, specifically CloudSQL hosted on GCP.

Leaving Remarks

• The project identified a book-lending system family that adhered to building a product within the scope of resource sharing systems.

• The book-lending system belonging to the resource-sharing family was successfully decomposed into separate microservices for specific use.

• The project successfully implemented the microservices architectural style with key patterns and characteristics including persistence isolation, inter-process communication, service discovery and reliability [3:26] - critical components for teaching the style.

• Further patterns such as decomposition by sub-domain were implemented per service to provide modularisation [2:87].

• Service APIs were defined to help further illustrate concepts of API contracts in software engineering as well as microservices aspects such as inter-service communication, and preference of duplication over coupling in relation to software architecture.

• Various deployment patterns were successfully implemented within the scope of using PaaS, illustrating the flexibility of the architectural style- allowing for various use cases in teaching software engineering practices.

• The system allows for greater software longevity compared to counterparts as:

  • Test-driven development, continuous refactoring and integration tests were used in order to illuminate any controller, service and repository failures

  • A conservative technology stack that is currently being used within the CS5031 module, being Spring Boot, was leveraged. The Spring Cloud toolset was further leveraged in order to adhere to microservice specific patterns such as the API-gateway and service discovery

  • The use of Kubernetes and the deployment of the microservices using Google Cloud Platform. GCP reduced complexity overheads of the system by externalising it's Java containerization tool, Jib- as well as providing in-house system monitoring when the system is running in production

  • Trade-offs between additional functionality, risk of deprecation and complexity were analysed for every pattern implementation

• The use of Spring-based annotations, templates as well as the use of JPA, provides software architecture students to explore the concepts of "architectural hoisting" [19].

• Within the scope of IaaS and the use of Kubernetes, the project successfully implemented continuous deployment practices, specifically the blue-green deployment strategy - providing a practical base for teaching software engineering principles and its relation to microservices.

• Monitoring solutions were explored within the IaaS scope and evaluated against other forms of monitoring solutions with teaching software engineering in mind.

• By adhering to the microservices architecture style, the system was able to implement different forms of architectural patterns in varying scopes such as:

  • Additionally implementing asynchronous messaging with RabbitMQ - thus illustrating how the system may evolve over time

  • Allowing for two types of service-discovery patterns to be used:

    • Self-registration patterns with Netflix Eureka

    • Server-side patterns with Kubernetes

Overall, the system is able to demonstrate key aspects of the microservices architecture style, a practical illustration of the benefits and trade-offs of this style. It can run locally or within a Kubernetes cluster on the cloud, with consideration for both software architecture and engineering students, thus providing a unique opportunity to explore an array of architecture and engineering aspects within the scope of a microservices-based system similar to those encountered in industry.